Closed zeffii closed 8 years ago
who is author of blog? I seee, it is you, thanks!!!!!! ))
@nortikin, maybe you would like to contribute a few geomtrydaily Node-ifications? I see now that I have to make a vertex-color node. http://blenderscripting.blogspot.com/search?q=vertex+colors
now i some busy, making interiors design and exterior + one album finished just now. I have todo, that i must do, and want prepare video teaser.
I'll make materials socket first (or implement just popup property in bakery and viewer nodes) to make materials... and vertex color too.
Color+material socket. I would like generic socket for input
strings - is generic i think. at least, i made it as universal.
it might be time to think about other datatypes, structs even..
datatype aside list? what should contain new type? name of data? maybe information of data structure to stop seeking of levelsoflists and stop checking for correction of data? or to leave it as is, only give new sockets for materials? we could out any data from material and vertex color to vertex group and armature binding. and splines and nurbs. that all will take so huge diversity of sockets, that we realy needs to rethink sockets type and consider smart solution on this. It have to be united somehow. would it be bpy_collectin_property or just dictionary? dictionary easy to manage, i think. never worked with collection propertyes and don't know how they manage lists-dicts. realy, maybe next socket should have alltogather ertices info about vertices? so we could create dictionary that will give corresponding values - dicts in dict or dicts in list or list in dicts how to manage materials to assign materials to vertices, to assign vertex colors to vertices?
{ 'materials': {'Glass': [1,2,3,6,7,8],... }, 'vertexcolors': {[254,254,0]:[...],...} } or something like that? it is for one object. before baking all data go to standart view in 3 levels, so it have to work [{{'':[]}}]
for vertices nothing have to be changed, as it is main socket type. And for matrices But for edges/pols there can be such: [{'curve':[1,2,0],'mesh':[0,1]}] etc
from curve and mesh values are the same as now - nasty list [[[]]] and more nested than {'curve':[],'curve_structure':{120:3}} where 120:3 is 120 length of curves count, and 3 - length of each curve. that way object contains all the data in dictionary...
maybe information of data structure to stop seeking of levelsoflists and stop checking for correction of data?
exactly, this would allow us to provide the information that the reading node needs to process the input. All good questions.
I would like to experiment with specialized containers, instead of the general python lists/dicts -- but because I have no experience with this yet I don't have anything to show at the moment.
we seeked in bpy.props - there is no solution for us. maybe we could create own bpy.props.Sverchok somehow... But it is hard, i guess and need C#
A class structure for more complex data types like curves would be a good idea I think, which doesn't make sense to manipulate on an atomic level like mesh data does. For meshes bmesh is the right solution. This would be good because the data atoms would become molecules. Which supports some general things for them like make a line for draw drawing, converting to mesh etc. But as long as we stay in python using list, tuple and dict etc makes sense because they are very quick and flexible.
Line
Polyline
Spline
Bezier
Long term the backend should move into c code inside of blender or something for speed. But right now I think an addon in python is a good idea.
Debug print node https://gist.github.com/ly29/accb020195c4de266f3d
nifty little node @ly29 ! will have a look at this later!
Updated to use draw button ext for individual sockets
ideally mathutils would have something like
mathutils.triangulate_polygon(vertlist, edgelist):
# magic in C
return vertlist, edgelist
It does kind of what you want. If we sorted the faces for rendering we could to that for all faces with length larger than 4. #157
if len(pol)>4:
glBegin(GL_TRIANGLES)
v=[data_vector[k][i] for i in pol]
tess_poly=mathutils.geometry.tessellate_polygon([v])
for a,b,c in tess_poly:
glVertex3f(*(data_matrix[i]*v[a]))
glVertex3f(*(data_matrix[i]*v[b]))
glVertex3f(*(data_matrix[i]*v[c]))
What is cool is that it takes many lists at the same time so it could be quite efficient I think.
We dont have to sort, just filter make vert lists based on index and now we support concave polygons.
perhaps for mkII I'll surpress the inner triangle edge drawing, or make it optional but that may slow things down.
Added the debug node but not in the menu yet.
updated todo, node_Script doesn't deal with nested lists.
a little experiment
what a PRO! instant sexy = Grease in Sverchok :)
I've opened it to all grease pencil layers in the .blend
I think for now I will just allow cache-ing, not update per frame (as each grease pencil layer can have as many frames as you'd want -- And I don't want to prevent any crazy user from doing that, but it won't be implemented yet).
with options
Where it makes sense to normalize first, then simplify (for 'optimal' verts to shape ratio )
i'm not sure it makes sense to add normalize and simplify as internal options, as separate nodes they could be used for a lot of other things. Time for a geometry_util.py
so we can at least use shared code for these things.
this might benefit from a 'close strokes where first and last point are within a certain distance from eachother` --
@enzyme69 GreasePencil node is probably not as useful as it first seemed -- at least I am now less convinced of its usefulness after prototyping it. The main reason is that it seems GP strokes usually need to be cleaned up manually before you import them. I've seen you do it in the video and i've found myself doing it while testing.
On the other hand, it does provide geometry quickly. Useful for testing Simplify, Smoothing and Normalize code. The exercise hasn't been entirely pointless for that reason.
Let's just add it with Beta tag :)
I updated the gist a few times, the caching doesn't really work. If a grease pencil stroke is removed from the blend, and you reload the blend the cache is invalidated.
Grease seems needs always to have the backup Curve created.
found and narrowing down spline normalize bug, using greasepencil to fake data.
Zeff, I just found out this option for Grease Pencil to Smooth and Simplify each stroke automatically.
If there is SV Grease Pencil node, we can probably have this Smooth and Simplify ON at all time.
Even if I added the greasepencil in
node to trunk it would provide no functionality that object _ in
doesn't already allow. I learned a few things by coding it so it's not a total waste of my time
It might ... say if I erase the Grease, it will auto update.
At the moment, I always need to convert Grease to Curve then to Mesh.
Then it makes more sense to implement Curve reading in Objects_in
, or dedicated Curve In
node
I still think Grease has something special about it. Easy to erase.
However, Curve In node will be interesting. Mesh convert on the fly.
I already have Curve to mesh code, written by Brecht http://blender.stackexchange.com/questions/688/getting-the-list-of-points-that-describe-a-curve-without-converting-to-mesh
What... You should have told me earlier. Been requesting such feature for years. I will try tomorrow morning... zzz
SN please or SV node please :)
object in could handle it. i implemented group input there. and think of adaptive sockets out for different objects. And that is why we need continue conversation on data in sverchok. {curves_knots:[], curves_handlersL=[], curves_handlersR=[]} where curve defined by first list, than if there no automatic handle type, it defines it coordinates as tangent.
i'm in favour or starting a curve_utils.py
to store these functions, to take a curve object inspect it and return edgs, vers, pols, mtrx
-- great for Object_in
node I agree.
yes, we can make functions for lofting? without nurbs. there is looptools where loft realised, and i guess, we could make couple of functions -
I think so. Started a different thread for this https://github.com/nortikin/sverchok/issues/198
http://bl.ocks.org/mbostock/dbb02448b0f93e4c82c3
this is one reason I wanted to get node.js in scripted node
I really like that kind of step by step interactive visualization of programming! It's like running the program in slow motion that our brain can understand.
I have a massive backlog of scripts written to test stuff (this list will grow as I remember where to find them)
# works on shaded
vectorlight = bpy.context.user_preferences.system.solid_lights[0].direction
that is right
I'm drawing up this list to keep track of things I want to complete before other random stuff.
node_scripts/zeffii/
current_file_CLONE_HHMM
(low priority)
(on hold, partially implemented or implemented but not committed)
done, presently in beta
=eval_text
(function, internal file, update)=read_text
(internal_file)done
vector * x
andvector * 1/x
.def sv_main(verts=[], dist=1.1, strength=1.0):
can easily be parsed and turned into in_sockets list.def sv_main()
. having a new import per iteration was a bad idea from the start