Tagging Sverchok generated meshes + future of bmesh viewers

[zeffii]

I think the tricky logic of bmesh / curve / typography is solved to some extent in the existing viewers, especially bmeshviewer2 shows how to use id properties like:

obj['some_property'] = (int, float , string...)

Allowing a string means it could hold complex json and store parametric data about the object. or it could store just an ID reference to a sverchok-database which holds parameteric information about objects

[zeffii]

bm_from_pydata

we use the bm_from_pydata because it turned out to be a convenient way to update a Mesh without having to delete the object and mesh first, there is no way to easily empty a Mesh data Object, whereas .

bm.to_mesh(obj.data)

works great..

I just realized that this may be just as simple:

import bmesh
bm = bmesh.new()
bm.to_mesh(obj.data)  # assign empty bm to Mesh
bm.free()
obj.data.from_pydata(verts, edges, faces)  # fill using existing from_pydata function

but it hasn't been tested yet..

---

smooth_all

ideasman42 has encouraged me to write a bmesh operator (in C) to do this - no ETA on that. bmesh_py_types.c is wehere we can be looking to make additions to profit sverchok (and anyone else using that feature of the API)

but this is not that bad..

def set_smooth(ob):
    mesh = ob.data
    smooth_states = [True] * len(mesh.polygons)
    mesh.polygons.foreach_set('use_smooth', smooth_states)
    mesh.update()

groups or parented

I find parenting quite a bit more useful than groups, and it should be perhaps a default behaviour so as never to overwhelm the outliner with 100's of real objects..

naming

well I don't know ... this is hairy code that solved a problem, i'm not convinced there's a more elegant way. It's not crazy to have full control over the object names, maybe the Empty used to keep them together should get the basename and all meshes should be basename+.0000(index)

[zeffii]

In any case, the implementation of these nodes all share a lot in common and should be a baseclass , maybe called SceneGeometryFunctions or SceneMeshHelpers , because it won't be bmesh specific.

[nortikin]

paranting. i made today that script to share objects over others.

import bpy
from mathutils import Matrix, Vector

obj = bpy.context.selected_objects

o = bpy.context.active_object
locata = o.matrix_local.copy()
data = o.data
name = o.name
for o in obj:
    if o.name != name:
        ob = bpy.data.objects.new(name+'_duplicatio', data)
        ob.matrix_local = locata
        bpy.context.scene.objects.link(ob)
        ob.parent = o

[nortikin]

the proposition is to put in rna the layout name to solve conflicts when copy bmesh viewers and generates two layouts with same name. name of object - weak part there.

[zeffii]

http://wiki.blender.org/index.php/Dev:2.5/Py/Scripts/Cookbook/Code_snippets/Properties

[zeffii]

My concern with using RNA properties is that the property gets added to all Objects in the scene, whereas a simple ID property is only added to the single object in question. With relative ease a collection of ID properties could work and hold the same kind of data as an RNA property.

Which fields / data points would the RNA need to store? The up-side to using RNA would be that we could make CollectionProperties, the downside it seems is that they aren't dynamic and all member types /props of a collection must be defined in the register() (or at some other point prior to using them).

This leads me to believe a truely adaptive method would be as a serialized .json string as an obj[id_property] , or even serialized dict (can be unscrambled with ast.literal_eval )

[zeffii]

the upside of serialized storage (dict, or json) would be convenient layout portability built in. parsing a collection property if you want to serialize a layout (like we do with the json exporter) is another point of pain.

I don't mean to be negative, but I have these concerns about RNA.

[ly29]

Id properties is a good compromise

[nortikin]

rna more global, sure you right, there is no strong need now to use rna, id is ok.