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 (I am doing the former).
Other than that, the EPoly implementation of Max is anything but bad, and far away from being half-edged…
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…