Home

Welcome to the BlenderPythonScripts wiki!

The highlight of this script is automated face(polygons) selection routines on a user specified (selection of a grid mesh). At the moment the use can specify by way of choice to selection and inset operator operations batch processing a given selection routine. The selection routine at the moment is based upon a neighborhood finding routine for a given surface selection face, for instance. In the 2 dimensional case, this selection finds all neighborhood faces for a given 2 x 2 sized grid for a given selection face. This procedure is iterated started from a given corner polygon, and repeats until having filled out the entire user specified selection area, or in other words, can create the equivalent of smaller selection groups from a large even selection overlay. Mostly I was motivated in designing such a script since, I hadn't seen an obvious workaround relative the procedure of having to select say 4 faces and then having applied an inset operation repeatedly, relative to select to select the entire selection area and applying the inset operation which would yield undesired/incorrect results.

As to other possible applications one might be able to use this, for instance, in subdividing a given larger selection area into smaller selection groups excluding a each face as a separate selection area as a trivial case. Mostly the purposes that I have envisioned for this involves modeling physically into a given model, 3 dimensional tiling attributes. For instance, floor tiles, that are actually raised above a given floor surface as opposed to textured with normal s or some other texture based displacement model that does this. Secondly the motivation this is based upon extending procedural texturing methods without requiring changes to the procedural texture itself in mimicking real world case that may be used in texturing methods otherwise. For instance, how to apply for a marble procedural texture the visual lines effect of grout in subdividing a given tile boundary line? One method that I could think of modifies the procedural texture literally in creating such visual boundary. On the other hand another method, uses an in iterated set of inset operations over face group selection data, followed by a batch extrusion of all such faces, to modify the mesh so that literally it is physically modeled with boundary tile to tile boundary lines/divisions.

MxN generalized case complete.

I also have thrown in some added scripts that I've worked, the past several years in so far as interface and modeling design. One being, for instance, a stair generator script. Although I haven't done so much extensive testing here, but maybe of use to someone somewhere: who knows?!

Another recent project of mine...of a purely heuristically driven challenge of mine is a script automating a Mondrian subdivision process. I were actually interested in a more generalized case, relative to say a three point subdivision process (or of this type) that I've more commonly seen online.
At the moment this script is incomplete and generally written so far without an ounce of correction in so far as testing. In any event, the scripting process actually works upon implementation on any given basis thoughts and potentially corrections supplemented by visualized problems in so far as rules and script alike. If you see me changing my rules, it is likely given to deficits concerning the matter of what clarity in rules do exist in so far as mathematical precision which is a customary approach of mine at times on the matter of self learning logic. I'd mention at this I weren't interested in compactly designing this code as succinctly as possible, but more interested in re layering or re incorporating existing code for re basing. A lot of this development process, thus given by the typical approach of working such problem in a graduated manner and then progressively designing were deficits have occurred. For instance, I had started the problem rationally to begin with the simple atomic logical nucleus: Constructing subdivision nodes. From this point, working upon the notion of randomizing subdivision crossing, where neither providing equality to all subdivision points in so far as crossing one subdivision line relative to the next, I logically proceeded upon the next idea of constructing a grid of interior node points, that I have called in this case crossing nodes that are given to randomized assignment of vertical or horizontal crossing assignments, deciding this given approach necessitating such. Then working from a model and conceiving a select number of structural examples, beginning the process of structuring rules that hopefully should work until having found deficits by way of example leading to contradictions by way of the given design of such rules, which lead to rules refinement or at least some corrective process. Thus it seems the challenge also here, without relying on any given script, implementing a refinement process, or in other words, this also being a logical reverse engineering problem likewise. In terms of code evolution here, I would work on the premise of keying and assigning, a separated group of nodes and crossing nodes alike, but found in retrospect, this leading to some potential deficits, and then also having neglected consideration for the boundary nodes here which would complete the entire subdivision map, and this would lead to a re base of the map which include grouping all nodes into one keyed map. In so far as constructing subdivision elements themselves, I have logically worked upon the idea of using nodes alone for implementation kernels as the subdivision drivers, and then secondarily driving any furthered subdivision constructions using crossing nodes or boundary points alike either such process later. Here it would seem an ordered construction method then having used the node firstly in a set direction and measuring crossings until reaching a non crossing point for instance, in such direction. While it hadn't occurred to me in keeping to any strict order, whether one might choose, for instance, either node or crossing node endpoint in the case, for drawing the completion of the subdivision area in a given orthogonal direction relative to either node or crossing node, I'd begin to settle on the notion of ordering the process by say a counter clockwise or clockwise drawing procedure. In this case, I also opted because the nodes themselves were neither fully inter relational in so far as one proving the same construction irrespective of direction chosen for a given node kernel construction manner, that an ordering procedure, coupled with a two edge construction method should be sufficient in defining a given subdivision area. A remaining logical problem here: ensuring that non subdivided construction areas are differentiated relative to already subdivided areas, that is, to avoid the problem of a re subdividing, for instance, over the same area. I had considered the possibility of, for instance, using a 'up' and 'right' construction method alone on such nodes, and then making a second pass for remainder unfinished subdivision areas to avoid the potential problem of back tracking over already worked areas, but this still hadn't fully dealt with the possibility of construction overlap (subdivision area intersections)...I'd mention avoiding intersections were in holding to say desired primitive geometry type (of a 4 edge type), getting outside this leads to polygons that, for instance, aren't strictly defined by 4 edges alone, and seems neither aesthetically Mondrian in nature. Thus, I am still desiring the a node construction method which is defined in 4 different directions as mentioned in the wiki rules. Finally, having a method to necessarily post flip crossing node assignments ensure alignment and not having edge crossing issues.

My intent is neither in laying out the script so much prior to any publication, but to evolve it as I am working through the problem here. Not that there should necessarily be any reason necessary in having stated this, or that any other process of doing so, whether simplified or not relative to such approach being the 'right' and only way.

4/25/15:

I've finished work generally for now on the Mondrian subdivision methods that I've set about aiming to do albeit I may consider adding implementation, for instance, in creating 3D models, or generally, creating and extruding walls from a given Mondrian subdivision set. Pretty easy to do since one can create subdivision offsets on such model in Blender using Inset operators, and then selecting the new walls (inverse selection of existing subdivision face indices). The alternate route would be in creating subdivision offsets directly in code, and then creating necessary faces as needed. The goal here potentially were not only creating random house/building floor layouts, but potentially in creating a random house modeling system.

A current project that I presently completing work on is a Gabriel Graph generator. This makes use of some methodology that I have seen in so far as Voronoi graph construction. One using cell type referencing system for ease in accessing neighboring nodes for directly testing, for instance, the disk comprising neighboring nodes, otherwise, brute force permutation iterating the entire set of nodes, as in the Voronoi case, is quite slow and poor for processing (and completely unnecessary). Alternate, methods for Gabriel graph construction might include things like the Fortune algorithm producing the dual graph of the Gabriel, and then converting this to a Gabriel graph, or lately as I have taken some considered interest in pursing a randomized Circle packing method. Screen shot of the Gabriel Graph generator shown below.

If you are interested in, for instance a Circle packing method here is a rough outline:

First pick a vertex representing a tangent circle center (1rst circumcircle).
Randomly pick a circle size/radii (reasonable constraints for the desired graph) for this circle. Using polar coordinates randomly assigning the direction relating between the first circle and a second circle. Randomly assign a size (using same random assignment constraints found in step 2 for circle 1). Now we can pack circles where randomly picking a polar angle (excluding that in step 3). For the next tangent circle again projecting from circle one. . As cited from a volume in the Journal of Computational Geometry (JoCG 6(1), 1-20 2015), Where tangent circles C, C1, and C2 are exterior relative to one another and C having origin O((r1+r) cos phi , (r1+r) sin phi), C1 origin (0,0) and C2 origin (r1+r2,0) and phi is the angle subtended from C1C2 to C1C then r = 2r1r2/(r2-r1(r2+r1)cos phi)-r1 .
We repeat the procedure of packing circles around the circle generated in step 1, until given to a desired number of edges. Then we repeat the steps of packing circles around remaining circles, all of this until a desired graph area has been filled.