FluidImporter
-
Wondered if anyone else was having trouble with this plugin?
I purchased this plugin 15 days ago and after more than 8 hrs of trying still could not get it to work! TIG's obj importer opened the files ok but not the new plugin which I understood to be a lot faster.
12 days ago I received an E-mail stating they were re-writing the code because of an "issue" and to be patient
, now not even the courtesy of a reply to my e-mails (20 in total).Mugged again
John
-
It works fine for me.
How big are your files?
-
Hello Rich, I've tried quite a few files to no avail. They said there's an issue with the code but I'm in limbo ATM with no return e-mails.
thanks
John -
Obj files have lots of options on export.
Depending on what those are can cause issues in SU.
Try importing the obj into Blender and seeing if an export again for there addresses any issues.
-
Thanks Rich, I've never used Blender. It doesn't seem to be the obj files that are the problem as TIG's importer opens them,
"Yes, we found what the issue is, but in order to solve it we need to rewrite parts of the plugin.
It will require a few days. I'll let you know when the issue is solved."I feel like a mushroom
John
-
Their importer is a binary compiled exe so it is much faster than my version.
However, I suspect that I trap for at least some file types that theirs does not.
Put simply, in an OBJ file the 'vertices' etc of a triangulated facet each have a 'reference' by their 'order' added into the file [v, vt, vn and facet f].
That order-reference is used to determine the related vertices that form the facet, their related texture's normals etc.
The standard OBJ way is use that reference later on as needed for the facet - e.g. f 11/11/11 12/12/12 13/13/13 [that is vertices #11/12/13 and the other equivalent order of normal data etc]
Although it's convoluted to extract the data for each 'facet', it is logical and doable...In the early days of developing my OBJimporter it became apparent that some OBJ files were failing to import properly.
I found that a few poorly made OBJexporters do not followed the 'official' way of referencing the geometry in the OBJ file.
In these 'rogues', although they order the vertices etc, any related facet in the file does not use the same 'order' references - instead they "counts backwards" to point to the linked parts etc - thus a facet might have some 'other_data' perhaps many lines much earlier on in the file, and so it then says perhaps f -66/-77/-88 -67/-78/-89 -68/-79/-90 etc - so now my code has to spot that, and from where the 'other_data' is located it has to calculate how it needs to look backwards at those lines earlier on in the file, to find those related vertices parts etc !
Because a 'properly' encoded OBJ file never uses negative reference numbers when referencing facets it is quite easy to spot a 'rogue' OBJ file type, and then apply the alternative [but even more] convoluted recalculation to get the proper connected vertex reference etc and successfully import these files...I guess if you open the problem OBJ files in Notepad++ you would find the second regime of referencing, which my code copes with but the faster/better code balks at...
-
Thanks TIG, I "sorta" understood some of that although code may as well be in Arabic to me
I figured out that even though I know zilch about coding I could have saved money by writing my own code that didn't work ...simples
John
-
We just released FluidImporter 3.1.0. You can get it here.
Here's what's new:
- Faster import
- FluidImporter is now a full .rbz extension, with a single file for Windows/OSX
- You can access FluidImporter funtionality through the menu Extensions -> FluidImporter
- Added edge smooth option
- Options are now saved so you don't lose your settings when closing SkechUp
Advertisement