"those pluggins are for those applications and not X frog. Well that's kind odd isn't it"...just my opinion Pete, I think this is a much better way with regards to better compatibility. The usual obj/3ds/dxf import formats from each individual do have problem sometime. Take an example I have experience with Billy-T bike models. It is make up of many parts (figure) to customize the bike you want...saving it as a Pz3 works ok most of the time but export as obj or 3ds from Poser, Vue has problem importing it. Another good example is with 3D Studio Max...most model exported from Maxs as 3ds file has high risk of "expolded" model issue when imported by Bryce or Vue, especially if the model has 500 seperate parts or more. To solve this problem, Max has a plugin made by Okino PolyTrans that has to be installed in Max plugin folder. Anything exported from Max PolyTrans works beautifully from obj....3ds..etc. Why?...well, I believe that the integration are much better this way and if I'm not wrong, PolyTrans may have to pay Max to have ths made and e-on too has to pay CL for that Pz3 import capability. If I'm correct, Right Hemisphere Deep Exploration adopted the same thing for Max stuff, that there is a seperate plugin needed to be installed in Max plugin. Like audity mentioned, it allows the host software to recognize directly the program use to create it, in this case, very compatible. Anout Onxy Tree, if you are into making profit modeling from it, I think you can't. It happened to the product "3D Forest". Their policy may have change but I doubt. Onxy Tree and Xfrog cannot be compare in a "apple to apple" situation, indeed both does tree but the emphasis of species type is Xfrog claim and also Xfrog can be use more for just trees and foilages. We had a Vue user did a crab and jelly fish out of it....LOL!...and me "alien birds" :) the best thing about Xfrog is that youcan create highly detail realistic tree species and kind and selll it...it does not have the "sticky" policy that Onxy Tree has. Xfrog tune was made to reduce the poly count for that same high count ones so that, these 'adjusted' lower count poly model can be use as "realtime" or distance "fill in" where detail close up is not required in a scene. Steve aka DigReal from Big-i is one such example that uses Xfrog to create his very detail tree for sale at Lyne site...I think. Anyway, Greenworks should not have crippled the obj and 3ds export format...they might as well do the same to the rest.I believe the mast majority user uses obj and 3ds more than any other 'monopolizing' high end program format...surely it sucks!