I made the same operations in V5 with the same model, it works normally.
I cant upload the rhino 6 WIP file if needed. The mesh was created with heightfield command directly in R6WIP.
Yeah send the file. http://www.rhino3d.com/upload OBJ export and, in the next WIP, import got a work over for V6. Itâs now written in C# and uses our own .net SDK. I tried testing it as thoroughly as I could with the models Iâve used in the past for OBJ before releasing it on users but you know how it goes. It would be good to see snapshots of the OBJ settings you used and also the mesh settings.
OK. Thanks for the model. It did seem to take a long time to open your model in the WIP on my computer, debug was way faster and thatâs rarely the case. Iâm not, however, seeing a slowdown compared to V5 for the actual export or the results youâre seeing. With regard to the chunky output check the significant digits in the formatting tab. There was a bug in earlier versions that had that set to 1 and it got saved as a setting if you ever loaded the OBJ export plugin. If thatâs set to 1 or something low(ish) youâll get results like youâre seeing. Set it to 17 and see if it makes a difference.
About the export speed : I tried to export a big mesh (4.000.000 faces) generate internally by heightfield in V5. With the V5 OBJ export, it takes ~40s to export. In V6WIP, with same parameters, it takes more than 2min.
RH5 export OBJ coordinates with points â.â while RH6WIP export with comma â,â. Is it due to national windows parameters ? Iâm in france. Anyway, it 's the reason why the mesh was so bad when import it after in Rhino (see the snapshot in my first post). It is not due to the âsignificant digitsâ parameter.
The âexport texture coordinatesâ parameter of the OBJ export module in V6WIP is not take into account. It is also not memorized in the option box. The texture coordinates are always exported actually.
Hope itâs help,
j
is a bug I missed because the C# number writing does pay attention to the culture. There is a way to write numbers and not pay attention to that though.
must be a bug in my code. Iâll get both 2) and 3) fixed asap.
Iâll look into 1) and see if thereâs anything I can speed up, it may just be a difference in C#/.net vs. C++ file writing. The code as a whole was only modified as needed to port it, no algorithms were significantly changed.
Does OBJ show up in the save as drop down? Does it show up in the list of plugins when you run PluginManager?
If yes, do you get the OBJ options dialog?
If yes, is it particular geometry or is everything failing?
If it is particular geometry it would be helpful to get an example.
Are you saving as meshes or curves and surfaces?
Just an FYI, in V6, OBJ I/O functionality was ported to RhinoCommon/dotnet. All of the functionality is actually in the SDK now and the plugins are for the most part only interface. I mention that in case thereâs some dotnet aspect thatâs preventing it from working. However, there are other dotnet plugins now that youâd definitely notice if that wasnât working. The circle command, for instance, is now in a dotnet plugin.
After seeing your answers we can dig deeper. I havenât heard of widespread issues with OBJ not working so I suspect this is an isolated case. It seems to work ok on my own computer using the in-house build from Monday exporting simple objects. Iâll get the latest public build in the meantime and give it a whirl.
Hm, so that exlains it, I used a folder that was under my user âJørgenâ and python never knew what to do with the âøâ. (In case you didnât know itâs the Norwegian vowel you use in âf-ø-ckâ) So that was probably passed on to the dotnet:
If I export to somewhere else that to a path containg odd characters, then itâs ok⌠butâŚ:
I noticed that if I open the exported obj file then it doesnât contain any layers, should it not add a default layer? The odd thing is that when I then draw something else then there are still no layers, but the new object is assigned to âdefaultâ even though that layer is not there.
Well, Iâve looked through the code and I think what youâre seeing is a remnant of the layer index problem. Whatâs happening is Rhino tries to use a bogus layer index (there was no checking in the code, there is now). That throws an exception that wasnât handled by the plugin. So the file writing bails. But whatâs worse is thereâs a file stream for the mtl file that doesnât get closed. So even if you created a new object in Rhino and exported that, if you used the same file name it would bail because it couldnât get write access to the mtl file. Closing Rhino would close the stream and youâd be able to write to that file subsequently as long as you didnât do the layer thing again. I tested this myself after determining what was happening and could write to a file path that had Japanese characters in it.
Yeah send me the model. While the V6 port wasnât a complete rewrite I did have to change the way a few things were written. With a model I can probably get it fixed pretty quick. Thanks.
Are you using the latest WIP? Iâm only asking because it opens for me in the WIP with no issues. Some sort of terrain model. When you open the file do you get anything, despite the error message? I also watched my memory usage on open thinking maybe it would peg for some unknown reason I wasnât aware of but it hardly used any. Can anyone else on this forum open, or not open, this file?