[kalle]

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.

The two tools are tested in Blender 2.6x (They may also work for 2.5x, but not older, as Blender has gone through major revisions) using Ubuntu Oneiric 64-bit and Windows XP. Precompiled (recommended) versions are available at http://www.blender.org

http://openfoamwiki.net/index.php/SwiftBlock
http://openfoamwiki.net/index.php/SwiftSnap

I encourage people to suggests improvements and make own versions. Based on Python 3.2, the scripts are very easy to understand and customise.

Kalle

[wyldckat]

Greetings Kalle,

Many Thanks for these plug-ins and documentation!
I hope you don't mind, I've taken the liberty to transcribe the documents into wiki format, as well as doing some formatting tweaks to the wiki pages.

I haven't tested the plug-ins myself, but I thought this would help boost the documentation side as well This way it will hopefully easier for people to make additional contributions!

Best regards,
Bruno

[kalle]

Thanks a lot Bruno!

I wanted to do that myself, but yesterday I ran out of time. Really good!

Regards,
Kalle

[gschaider]

Originally Posted by kalle

Thanks a lot Bruno!

I wanted to do that myself, but yesterday I ran out of time. Really good!

Regards,
Kalle

Have you guys tried using the MediaWiki-Export-Plugin for OpenOffice? (just curious how this works. Never found the time to test it)

[wyldckat]

Hi Bernhard,

Originally Posted by gschaider

Have you guys tried using the MediaWiki-Export-Plugin for OpenOffice? (just curious how this works. Never found the time to test it)

I've never tested for at least two reasons:

• The articles I've been copy-paste-formatting from PDF/ODT to wiki rarely have sufficient formatting to make it worthwhile using a more advanced export tool. So I didn't bother looking for it.
• Installing plug-ins isn't always straight forward...

Best regards,
Bruno

[gschaider]

Originally Posted by wyldckat

Hi Bernhard,


I've never tested for at least two reasons:

• The articles I've been copy-paste-formatting from PDF/ODT to wiki rarely have sufficient formatting to make it worthwhile using a more advanced export tool. So I didn't bother looking for it.
• Installing plug-ins isn't always straight forward...

Best regards,
Bruno

OK. Was only asking (that's a quite satisfactory answer). About installing: I'd forgotten about it but recently saw that it is included in the LibreOffice-RPMs ... that would be quite straightforward

[kalle]

I've added an example case for SwiftBlock on the wiki.

[kalle]

... 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.

Kalle

[kalle]

Another case added for SwiftBlock, the same bent T-junction as above, but using blockMesh instead of snappy.

I will give a talk on these two tools at the upcoming workshop also.

K

[kalle]

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

[gschaider]

Originally Posted by kalle

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)

[kalle]

Hi!

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?

K

[gschaider]

Originally Posted by kalle

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

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

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

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

[wyldckat]

FYI: I've updated the two wiki pages: "v2.6x, with x<3."

[kalle]

Thanks Bruno for the 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.

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.

K

[gschaider]

Originally Posted by kalle

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.

Looking forward to meeting you at the workshop

[wilker]

does it work for the 2.6.3 already?

[kalle]

Hi,

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.

K

[kalle]

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.

K

[wyldckat]

Hi Kalle,

Two questions:

1. Is it still only compatible with Blender 2.62 and below?
2. I'm guessing the file you're referring to is this one: http://openfoamwiki.net/index.php/Fi...tblock.aug.tar - is ".aug" a special file extension?

Best regards,
Bruno