For some time I have been working on writing two python plug-in scripts for Blender 3D. The two tools assists the user in creating the blockMeshDict and snappyHexMeshDict with associated files. The tools have no interdependencies, but the users may use SwiftBlock to create more advanced base meshes for snappyHexMesh than just a single block.

I have the hope that the tools are easy to use, but please read the short user guides before starting. If anyone encounters problems, please bring them up here on the forum.

... and now there is also an example case to download for SwiftSnap - see the wiki.

One note though: Blender is not known for having great compatibility between versions. Both example cases have been made in v2.61 on 64-bit Ubuntu. I do not know how well these cases open on other Blender versions and/or OS's.

I just found out that Blender has undergone a major update on mesh handling with v2.63; faces can now have any number of vertices, compared to 3 or 4 in previous versions. This change also influence the python scripts and renders both my tools unusable with this version.

I just found out that Blender has undergone a major update on mesh handling with v2.63; faces can now have any number of vertices, compared to 3 or 4 in previous versions. This change also influence the python scripts and renders both my tools unusable with this version.

Hence, I recommend to use 2.61 and 2.62 until further notice.

K

THAT explains the problems I've experienced with version 2.63

BTW: are you planing to put your scripts under version control (git, mercurial, ... anything) somewhere (bitbucket, openfoam-extend, ....)? That would ease deploying intermediate versions to those interested in testing (I'd propose organizing the repos in such a way that a clone of the repo in addons_contrib yields a working version)

Good to have caught an issue. Please post here if you have troubles. Both tools should easily be applicable to the default start-up Box in Blender.

It seems to work to just replace all calls to xxx.data.faces with xxx.data.polygons in both tools. You can also remove the whole "def faces_from_mesh" function, as it is not used.

I had a feeling that revision control was overkill for these tools... now I start to realize it might be useful, especially as there will have to be different versions for different Blender versions. How can I commit to the extend project?

Good to have caught an issue. Please post here if you have troubles. Both tools should easily be applicable to the default start-up Box in Blender.

Wanted to verify first whether the problem was a PEBCAK (Problem Exists Between Chair And Keyboard) before asking. You were faster

Quote:

Originally Posted by kalle

It seems to work to just replace all calls to xxx.data.faces with xxx.data.polygons in both tools. You can also remove the whole "def faces_from_mesh" function, as it is not used.

Nice thing about Python is that you can handle both versions in the same code with exception handling. Something like

Code:

try:
val=foo.data.faces
except AttributeError: # I THINK this is the exception
val=foo.data.polygons
# use val (assuming it is still the same)

could work (haven't looked at the actual code). Of course it doesn't increase the elegance of the code but it helps to avoid having different versions of the code

Quote:

Originally Posted by kalle

I had a feeling that revision control was overkill for these tools... now I start to realize it might be useful, especially as there will have to be different versions for different Blender versions. How can I commit to the extend project?

Revision control is never an overkill

You need to be granted write-access. If I put on my admin hat this is possible ...

About the choice of the VCS. That depends on what you're comfortable with. The two basic options are:

Subversion: the advantages of this are

flat learning curve

partial checkouts. That would make the "install Plugin by cloning quite easy"

On the other hand branching is ... awkward. But with SVN we'd only have to negotiate a place in the global tree where you put your stuff

Mercurial/Git: These are technically equivalent (from the outside. Mercurial is Python while Git is .... not so elegant). Branching is quite easy. Disadvantage is that they don't have partial checkouts. So you'd need a separate repository for the "clone to install" to work (but we can do without that if you want to keep both utils in one repository). Here we'd have to create a separate repository for you

Thank you too Bernhard for the tip. try/except looks like a suitable fix. I'll get back to you on how to proceed for revision control. We could also speak at the workshop.

Another issue with swiftSnap. If a refinment region is hidden when you write your dicts & stl files, Blender will create an empty stl-file for the refinement region. This is particulary annoying since the user will not be warned, but snappy will crash with a FPE. Keep your objects visible. I'll make the code turn on visibility for the refinment objects in an update.

Thank you too Bernhard for the tip. try/except looks like a suitable fix. I'll get back to you on how to proceed for revision control. We could also speak at the workshop.

This try/except-trick is like #ifdef (except that it happens at runtime): very handy if you don't want to keep two separate sets of the code but it doesn't improve the readability of the code and makes it easy to "overlook" errors in the "lesser used" branch of the code.

I have been trying out 2.63 on my machine, and it can run after some modifications. I feel the code will be a bit ugly if it should be compatible with both 2.63 and 2.62, so I did not release it though... however, you can find 2.62 on Blender.org.

Ok, folks, a new version is here. Now you can set edge resolution and force edges to have certain resolution, by overriding the values automatically calculated. There is also a diagnose button that will mark any edges not participating in the block structure, typically indicating some error - saves some headache. You'll find it on the wiki.