Hi!
I have just looked into xmesh. And was disaponted to see that the objects was converted into tris. I understand the concept of the renderer internaly converts everything to tris.
I saw the script you provided. Thanks, but how do you use this? I have no scripting experience. Is there any chance you could add an option for outputing to polys instead. Sometimes it is important to keep it that way. Especially in the case where a turbosmooth is involved.
daniel
Another exampel. Say you want to bake out a particle system with geometry instances. Some of the particles might get close to the camera so you need to make sure the particles has enough polys. As things are now you would have to make a massive hires bake since polys / quads aren’t supported in the UI. Sure you could make a proxy bake but you would be locked to the baked resolution either way.
Maybe in hardcore destruction vfx work the the tri solution is good but my workflow always ends with a turbosmooth so I can crank up the resolution. Is it possible to implement full support for polys? If not I will have to fall back to Supermesher and various scripts for my bakes.
Hi Daniel,
XMesh DOES support polygon meshes internally due to the way some other 3D apps represent their data, so we will expose this in the 3ds Max version in the future.
But keep in mind that XMesh was designed to capture the geometry just before rendering, and was mainly used to simply separate the rendering stage from all previous stages. In other words, one would perform all modeling and animation in 3ds Max, then, instead of rendering the scene directly would save the results to XMesh and then have a light-weight scene sent to the render farm, reading from the XMesh caches and reproducing the EXACT same results at render time. It works great for Frost, Thinking Particles, Particle Flow and general scene objects, but I can see how it does not cover your workflow.
In addition to real polygon support, we could also add an EdgeVisibility channel to make TriMeshes appear as polygons when loading (the way Editable Mesh resembles Editable Poly by hiding edges between faces). It is on the Wishlist, but it was deemed less important so far. Looks like it isn’t 
You are right that adding TurboSmooth to an XMesh would not work right now, but it wasn’t originally meant to be used that way. We will look into providing that ability ASAP!
The XMesh Saver does not require any scripting knowledge, only basic 3ds Max knowledge (Customize User Interface > drag ActionItem from “Thinkbox” category to a toolbar).
thinkboxsoftware.com/adding- … -mx-to-ui/
For people with MAXScript knowledge, XMesh provides the ability to develop their own tools around it, but it is not a requirement, it is a bonus.
Please let us know what part of the XMesh Saver installation and usage is confusing so we can fix the documentation!
Hi Bobo
Thank you for your swift reply.
I can see why and how xmesh was developer. It certainly is a great tool if you want to strip a scene and send it out to rendering. That said the tool has so much more potensial in the form of general workflow, not necesarily in the rendering stage, if poly mode would be exposed. We’d like to implement as many of your tools as possible (we just switched to deadline) simply because we think they are “nextgen”. Please look into this and feel free to contact me if you would like some input.
Best
Daniel