Editable Mesh vs. Editable Poly: What's the logic?

#1

I’ve read through some of the commentary about these, but I’m still a little puzzled: Why are there two very similar, but not quite identical, toolsets for things that are as closely related as this?

Is “tris vs. quads and n-gons” a distinction that’s so important that they warrant these confusingly similar tools?

I’ve found that the polys toolset has a little more functionality for me-- I like “hinge” and the numeric tabs.

But I still don’t get it-- is there an underlying logic here that I’m missing? Or is it simply the “user’s view” of a software design issue?

#2

editable poly is the newer toolset that replaces editable mesh sort of. but for compatibility reasons and of course for those who do not like to change their workflow, discreet probably decided to keep that oldie.

you can find that kind of fat in a lot of applications that have grown over the years.

#3

There are still some things, though, that you can do in Editable Mesh but not in Editable Poly. Like, Ignore Visible Edges, quickly turn edges, and weld any verts you want. And for some game engines, models need to be exported using EMeshes, not EPolys. So I still use it for those reasons, but I prefer to do most of my modeling using EPolys becuase overall it’s quicker.

#4

Originally posted by Crocodilian
[B]I’ve read through some of the commentary about these, but I’m still a little puzzled: Why are there two very similar, but not quite identical, toolsets for things that are as closely related as this?

Is “tris vs. quads and n-gons” a distinction that’s so important that they warrant these confusingly similar tools?

I’ve found that the polys toolset has a little more functionality for me-- I like “hinge” and the numeric tabs.

But I still don’t get it-- is there an underlying logic here that I’m missing? Or is it simply the “user’s view” of a software design issue? [/B]

Historically, 3D Studio DOS and then MAX were based around TriMeshes from the beginning.

The logic is that from a mathematical point of view, 3 points always define a unique plane, it is painfully easy to calculate the normal to that plane (by normalizing the cross product of two edges of the face), and thus it is very simple to render a triangle.

N-gons (where N is 3 or more) usually have to be broken down to triangles at a certain stage of the calculation in order to be able to calculate the normals and the shading of the surface.

The EPoly is not just another way of looking at things, it is based on a completely different internal data structure. Originally, it was developed by the makers of the Nendo and Mirai software (whatever their name is today).
The popular name of the technology is “Winged Edges”. The implementation of this new data structure started during Max 3 development (but there was no UI exposure in 3), then the basic UI came in Max 4 and was extended by Laszlo Sebo’s Meshtools, and matured in Max 5.

What is the difference?

In the case of TriMeshes, the basic building blocks of the geometry are vertices (stored in a vertex array) and faces (each one expressed as a Point3 value where .x, .y and .z components are indices pointing at one of the vertices in the vertex array).
Edges in this structure do not actually exist. Each face has obviously 3 sides defined by the line connecting vertices 1-2, 2-3 and 1-3, and there is a flag in the structure recording the visibility of that edge. BUT, where two faces share the same two vertices, they don’t share a common edge! Each face has its own edge and when changing the visibility of the one, MAX has to make sure internally the opposite one of the neighbour face also gets changed… All in one, there are 3 times as many edges as faces in a TriMesh, since every face has 3 of them. But finding out which edge lies between two vertices or which faces are sharing the same vertices along an edge is rather slow as the whole mesh has to be traversed to find out. As the mesh density increases, this search time gets longer and longer.

In the case of EPoly though, the basic building blocks of the geometry are vertices and EDGES! Polygons are defined by the edges, not the other way round. This means that finding edge loops, splitting edges, cutting through hundreds of thousands of edges with a slicing plane etc. are very fast since the edges are a structural element of the geometry and VERY easy to locate, query and change. Also, two neighbour polygons sharing an edge actually use the SAME edge, so manipulating that edge alters both polygons with a single operation.

A drawback of this structure though is that by definition, an edge can be shared by 1 (open edge, like the outside edge of a 4x4 plane) or 2 (internal edge, like the inside edge of a plane) polygons ONLY! You cannot have 3 polygons sharing the same edge (the case is called a “rat’s nest”), which explains why it is not possible to select an internal edge that already has 2 polygons and extrude a 3rd polygon by shift-dragging.
(If you convert to EMesh, shift+drag edge and convert back to EPoly, you will discover that the new poly is a “free-floating element” and not actually attached to the surface it was extruded from - it has no common edge and vertices with the original edge that was extruded).

Another drawback of EPoly is that the graphics pipeline that supplies the realtime renderer with triangles (can be SZB, OpenGL or Direct3D accelerator) has to do some extra work to convert the EPoly data to TriMesh to be displayed in the viewports. So while cutting through an EPoly mesh is much faster than with EMesh, the display is much slower. It also explains why adding a MeshSelect or TurnToMesh to the top of a non-animated EPoly makes it many times faster to redraw in the viewports…

Hope this helps!

Cheers,
Bobo

#5

there are some more stabilty problems with e-polly, so says Dave Dorman. i’ve not encountered these yet though

#6

Wow, Bobo. Very nice explanation :thumbsup:

Perhaps you can put these little gems in a new FAQ on your site, along with the post about the history of 3ds (max), amongst other things :slight_smile:

  • Rens
#7

Originally posted by Rens Heeren
[B]Wow, Bobo. Very nice explanation :thumbsup:

Perhaps you can put these little gems in a new FAQ on your site, along with the post about the history of 3ds (max), amongst other things :slight_smile:

  • Rens [/B]

Unfortunately, the latter one (the history) was lost when the CGTalk server died a couple of weeks ago. If anyone has a copy of it, please email me!!!

We should put these things in a FAQ on THIS site, it gets more visitors. :slight_smile:

#8

I suspected something of the kind-- an underlying architectural issue-- but I didn’t know what it was.

Thanks to all for a very detailed and useful explanation of this topic!

Croc

#9

Indeed, a very interesting read Bobo (especially the historical evolution of Max and polyhedral objects). Thanks for taking your time :slight_smile:

Marsel

#10

Bobo: That was awsome as usual.

Being a Mod, I would love to put up some sticky threads filled with your sage wisdom. :smiley:

Contact me VIA PM if you are interested.

-Dave

#11

You can read more about the e-poly data-structure here:

http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/model/winged-e.html

#12

Originally posted by Bobo
The EPoly is not just another way of looking at things, it is based on a completely different internal data structure. Originally, it was developed by the makers of the Nendo and Mirai software (whatever their name is today).
The popular name of the technology is “Winged Edges”.

Are you sure it’s a winged edge system? Max looks like a half edge system to me.

#13

Tnks for the input Bobo, very very nice!!

All this conversion from EPoly to TriMesh in necessary because Max structure just can show TriMeshes on the viewports or is a comom task to all other programs?

EPoly isn’t slow because of it’s structure?

Is there any way to make an EPoly show directly without any convertion?

Sorry I’m losing myself here in my poor english.

#14

Originally posted by PiledotNET
[B]Tnks for the input Bobo, very very nice!!

All this conversion from EPoly to TriMesh in necessary because Max structure just can show TriMeshes on the viewports or is a comom task to all other programs?

EPoly isn’t slow because of it’s structure?

Is there any way to make an EPoly show directly without any convertion?

Sorry I’m losing myself here in my poor english. [/B]

You should bear with me as I am not the developer of these technologies and might be very wrong sometimes…

Originally, 3D Studio MAX 1.0 was designed around the HDI graphics pipeline. (We know it as Heidi today, HDI stands for HOOPS Device Interface, and HOOPS stands for Hierarchical Object Oriented Painting System or something like that) This graphics system was developed by Ithaca Software which was then acquired by Autodesk. It was also used in AutoCAD (originally in the so-called WHIP plugin for speeding up drawing browsing, I assume it is an integral part of later AutoCAD versions).

Heidi is a high-level scene description system which has great software support (when Max 1.0 came out, only 3D Labs had chips that would accelerate it, and not too many users had cards with GLiNT chips at that time). The drawback was the need for a special driver that would access the hardware acceleration, so the call for OpenGL support was loud.

In Max R2 in 1997, OpenGL was implemented by Don Brittain, but the internal geometry pipeline was still based on Heidi.
After the modifier stack calculates the final TriMesh representation of an object, the triangles have to be sent to the OpenGL driver in the best possible way.
OpenGL has lots of ways to transfer geometry from the main memory to the graphics card. The slowest way is to send each each triangle separately. It is faster to send an array of vertices and an array of faces. (Even faster, you can send so-called triangle strips so you don’t have to send common vertices too often - Max is trying to perform triangle stripping, but I don’t think it is very efficient).
One of the fastest ways is to store the data arrays in continuous memory segments and just send OpenGL pointers to the beginning address - OpenGL then just copies the complete blocks into the memory of the graphics card.
The transfer in the first days of Max 2 was over the slow PCI bus, then AGP in all its versions came around. Max 3 added support for the Generalized Vertex Array extension, but after that point, it was mostly left as is and Discreet concentrated on getting Direct3D to work better. OpenGL would be capable of caching meshes on the graphics card memory (John Carmack was doing this with the static environment models in Quake for years), but we have this option only in Direct3D. Basically, the geometry data is sent to the graphics card once, and if it is not changing, all consecutive redraws access the mesh from the fast graphics card memory and skip the transfer from Max to card completely.

In the case of EPoly, the structure itself is not slow, but the data is not suited for immediate sending in any of the available OpenGL data transfer methods. So there is some additional work involved in preparing the data in the desired format. (or at least that is what I understood from the developer’s explanation).

Obviously, an application and a graphics pipeline that has been built from ground up to work with EPoly-like structures would perform better. But with the given development history, the combination of an after-thought OpenGL implementation and an after-thought Editable Poly system on top of a core that is currently about 10 years old just cannot deliver the fastest results. We can either use what we have and wait for a new core, or switch to another package, just not Maya :wink: (I am doing the former).

Other than that, the EPoly implementation of Max is anything but bad, and far away from being half-edged… :wink:

About the TriMesh conversion - the modifier stack has a validity interval and will update whenever something changes the geometry. In cases when the model is basically static (no vertex movements or topology changes over time), the conversion to EditableMesh on top of the stack using a TurnToMesh or MeshSelect effectively CACHES the result until something changes below it on the stack and invalidates the result. This means that rotating around such an object is VERY fast because the TriMesh is already existing on top of the stack and is just being sent again and again to the graphics card. Moving a vertex though would cause a reevaluation of the stack and slow things down (plus the need to create an undo record for the change).

In the case of Direct3D with enabled D3D Mesh Cache, the geometry is not even being sent all the time, it is sent once and then redrawn from within the graphics card memory. I am measuring around 15 million faces/second on my ATI Radeon 9600 card using that mode…

Once again, this is my knowledge as a long-time user, I might be completely wrong regarding most of the technical stuff…

#15

Cool Bobo, thanks for the info.

just to clarify, using lots of EPolys and I have some at the moment that are very dense, using openGL and turntomesh will be the best setup?

is it better to just convert to EMesh and back again when I need to remodel?

#16

Originally posted by JayCMiller
[B]Cool Bobo, thanks for the info.

just to clarify, using lots of EPolys and I have some at the moment that are very dense, using openGL and turntomesh will be the best setup?

is it better to just convert to EMesh and back again when I need to remodel? [/B]

The original concept of Max is to be procedural.
Adding a TurnToMesh on top is the better way.

#17

right grovey, also will the render times be quicker if I just use EPoly or that doen’t matter?

I’m also using edit mesh with auto edge to clear all the edges and I get just a box that has no probs with updating viewports.:buttrock: Im asuming that there isn’t anthing there that will cause problems latter on.

#18

Can’t find a word in English to express how I’m thankfull Bobo!!!

Now I can understand the tools diference between EPoly and EMesh, and other details.

So why they didn’t create an Editable "Thing" that works with Vertex/Edge information and use triangles as structures?

Sorry I don’t want to take you time but chat with you is very nice!

#19

Well putting an Edit mesh ontop made the file size balloon out so thats not good, I should have just coverted to EMesh to begin with.

#20

Thanks for the useful info, in explains a lot, but a have a question:
I have usuall modifiers setup for modeling, Editable Poly>Turbo Smooth and truth: applaying turn to mesh speeds up things, a have mesh caching turned on on direct draw, so it does not make a short pause before panning. But when I apply turn to mesh file size increases from 1mb to 47mb, Why? What is better than to work wit or without Emesh?

“We can either use what we have and wait for a new core, or switch to another package, just not Maya”
Why? What’s wrong with maya?

Thanks again