I’ll probably be poking at this a lot over next month. Would you rather I post feedback here or I noticed you posted in Blender Artists forum as well?
Aye, instances aren’t nicely handled yet, although it can be possible. I have logged
Either place is fine.
Thank you. This way is working. I just copied the “
rhino3dm” folder from “
C:\Users\-\AppData\Local\Programs\Python\Python37\Lib\site-packages” into the “
2.80\scripts\addons” folder and now also working here.
I hope we can streamline this at some point, but for now you all get to be my guinea pigs
Nathan - moving our conversation here as requested.
I am attempting to address the changes required to merge the pull request, but I am in on way a git expert… My branch was several commits ahead and a few behind so to make this “easy” on myself i have deleted that fork archived my local copy and created a new fork with a new branch. As this current pull request will be about changing the project structure I am going to commit a new branch sans any of the features i have added but with the full new project structure I am proposing. Does this make sense?
For future reference: you don’t have to delete your fork in the future. When working on anything for the importer the single most important thing to remember is to always work in a branch in your fork. Don’t do anything in the master branch of your fork. You’ll use that to pull any new changes that may have happened in the upstream repository (my repository).
So, to get the PRs going as I had requested in my code review you can indeed start a new branch on your repository. In that you make the necessary structural changes as you did in your first PR. Mind you to not include any new feature code. When you have made your structural changes you can make the PR as you did with your first attempt.
You can make multiple commits for your branch, but I very well might be squashing them together - nothing you have to worry about though. You will still be the author of the changes (:
Once that PR is in you can ensure you have your fork synced with my repository (upstream). GitHub has clear instructions on how to do that. When done with that you can create new branches for your feature work.
No matter how small a feature is I prefer them to go into new branches. That keeps my work manageable and I hope we can get to a clean commit history that documents well what happened and why.
I appreciate your efforts!
I knew the moment I deleted it there was a “better” way but I had polluted my master branch and it just seemed easier… Seems to me a good read on git is in my future
I have issued a pull for structural changes. Once I work out any changes you request going forward I will work on these in the following order.
- Upgrade the latest Rhino3dm and implement unit checking and miss match between files.
- Hidden Geometry handling (can this be done with hidden layer? as hidden objects so one feature?)
- Hidden Layer handling (see above)
- Overwrite/duplicate geometry on import
- Overwrite or keep existing blender materials
- Open to working on curves or other elements as they become available in Rhino3md
Github has some really nice docs to help get you started on the process of creating pull requests.
Thank you for submitting your PR. I’ve reviewed your PR now, mostly cosmetic changes, and it should be good to get in. I leave the honor of making those changes to you. But all in all it is a good PR.
The single most important part of the review is to not use blanket asterisk imports. Lets keep the submodule names around - it is ok to alias them if you think the names stay clear and usable. I made some suggestions regarding those. I’m guessing that with your work to get this going well with Visual Studio Code this won’t be an issue.
Don’t forget to update the requirements.txt file.
I think the way to do that in Blender 2.8 is to create a collection that isn’t linked to the scene, but does have its usercount set to 1 so that it gets saved, not purged.
The options added/requested originally meant that one could select to import hidden geometry and hidden layers instead of just skipping them. I would stick with that, and then later add an extra option to control how these are imported: ‘hidden’ (not directly linked to the scene) or visible as currently would be the case.
Do you mean to add options for that?
Sure! Anything you feel you want to add you should! When in doubt you could create a feature request as new issue on GitHub where we can hash out how it should work.
Once again: thanks for your efforts!
I think ideally it may be better to simply keep it in the same collection but turn off its visibility no? But I will implement the simple version of simply skipping them first and we can get feedback.
There is an issue for updating and duplicating geometry now and I will implement it but there is also a glitch with the way we handle materials at the moment. If you import a file and make changes to the materials and then re import the file with some new geometry it will override the material and all of the changes. This needs option so that one can maintain the material changes in the blender file.
That was the original intent, but
This I meant for hidden layers. Hidden geometry we should be able to create so that they are hidden in Blender as well, indeed.
is a good feature to have.
Same goes really for geometry.
FWIW I made a first release as v0.0.2. A zip that users can now use to install.
Still needs manual installation of rhino3dm.py though.
Hi. have tried it and works really well.
Does 0.0.2 work with Blender 2.8?
And is it possible to import rhino curves? For now only the meshes apear… Cheers
0.0.2 works with Blender 2.8 yes. Currently the import_3dm development is being done solely against Blender 2.8.
Curve import is not yet done, but already logged as a feature request.
whoops. stupid questions… thanks for the repies…
im looking forward to bring linedrawings from rhino to blender
could be the alternative to acad to 3dsmax workflow.
I just pushed a new branch that adds in basic unit handling on import.
The three options are:
- Ignore - “default” Assume the user knows what they are doing (working as before no change)
- Convert Rhino - Convert the incoming rhino file into the current Blender unit system (working somewhat)
- Convert Blender - Convert the current blender file into the incoming Rhino unit system (not working yet)
Importing a file and converting to Blender unit system works however I am not happy with it at the moment as I cannot seem to apply the transformation on the objects. They are imported be to the correct unit system size but also their scale factor should be (1,1,1) as as of now it is not.
The plan here is to be able to resize all objects to the incoming Rhino unit system but in the end maintain each objects local scale settings, assuming that the user may have scale objects and wishes them to maintain their relationships.
I have posted over in the Blender Discord for help with applying transformations. I will make a pull request when i get this worked out. Hopefully soon.
I assume you mean blenderartists.org? I couldn’t find the topic for this. A link perhaps?
For the unit system conversions you’ll end up only scaling really. Since all Rhino objects are effectively at world (0,0,0) you should just apply the scale transformation with (0,0,0) as the scale center.
Once done you should apply the scale transform:
bpy.ops.object.transform_apply(location=False, rotation=False, scale=True)
No the dev talk similar to this channel here for Rhino
Yes this is exaclty what I do and it works well but the apply transformation fails. See my post
Ah, hmm. I think we need to create our own context here so we can set the necessary bits and pieces so that the
transform_apply works. That way you don’t have to do
select_all, which can be dangerous if you’re importing into a file that has already geometry.
a quick look in Blender source code shows we need to set
selected_editable_objects of the context with the object(s) we want to apply the transform of. Here is how I use that already in the importer: https://github.com/jesterKing/import_3dm/blob/master/import_3dm/read3dm.py#L81
You should be able to use that on
transform_apply as well (not tested here, but it should!) - give in a dictionary with
selected_editable_objects as key with a list of objects. In the line I linked I use the top collection accessor
all_objects which gives nicely a list of all objects we’ve imported.