[Bf-committers] ctypes wrappers for blender
Hi BlenderDevs, http://rpythonic.googlecode.com/files/libblender-ctypes-test2.tar.bz2 Above contains a ctypes wrapper around a large part of the blender C API. Also included is a blender.h header file that the wrapper is generated from. I wasn't sure if there was some more headers that should be included in there, so far its just a starting point. The archive includes libblender.so compiled for 32bit ubuntu. The ctypes wrapper (blender.py) can be used from within blender by having ctypes load an empty string, telling ctypes to load from the current process, in case your not interesting in using libblender.so -brett ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Some ideas to improve the "Add-Ons" section
The Addons system badly needs a "recently added" list, that should be the default when going to UserPrefs>Addons. The most common question i get from users of my addons is "where do i go to enable it". Even if i put in the addon README UserPrefs>Addons>Somecategory>myaddon, few seem to figure that out and get lost is the long list of addons presented in the Addon panel. -brett --- On Sun, 5/22/11, mindrones wrote: > From: mindrones > Subject: Re: [Bf-committers] Some ideas to improve the "Add-Ons" section > To: "bf-blender developers" > Date: Sunday, 22 May, 2011, 1:43 PM > Hi! > > On 05/21/2011 12:31 AM, Doug Hammond wrote: > >> > >> - Ability to keep addons in sync/update with an > online repo could work > >> but am wary of this turning into a package > manager, we would need to > >> have a branch for each release so addon devs could > work on extension > >> trunk as well as the release branch so users get > updates too. > >> Since this needs buy-in from existing addon > developers I rather leave > >> this for a bit since addons are being actively > added/written/removed > >> and the addon community is still quite new. > > > > > > I though work in this direction was already under way, > I remember discussing > > at length > > with mindrones about addon metadata, development > branches, stable branches, > > binary module URLs etc etc... > > > > What happened to all that effort? > > > It's a bit on hold due to my work on the wiki maintenance > and real life > small disasters (like having to relocate twice :) > > > Some times ago, when we've setup the new wiki server we > have also setup > a virtual host for the addon dispatcher application that > will distribute > updates for trunk/contrib, but also for externals addons, > like > luxrender, yafaray, gamekit, etc... > > > As Doug said, the design is already setup, see > http://wiki.blender.org/index.php/User:Mindrones/Bf-extensions/External_addons > > All in all we have dsicussed at length, so we know well > what to do, it's > a matter of doing it. Sorry to be late on that :/ > > > As Campbell said, we will need to work on branches, so that > if a > developer has updates for a blender version that has > already been > released he will have to commit in branches, here: > https://svn.blender.org/svnroot/bf-extensions/branches/ > > If you download a certain version of blender and a > developer makes a fix > on branch for your revision, you would get notified and > download the new > version. But it's not that easy because some people develop > scripts in > the scripts/ dir, so just overwriting the current script > with a new one > might be undesirable for some people. We need to think > about a temp/dev > folder to store stuff when we update. > > > About external scripts, there has been a long discussion > with Ton in > #blendercoders: > 1) if a script is developed outside of bf-extensions, like > on github or > so, BF will only work as mirror at > https://svn.blender.org/svnroot/bf-extensions/extern/ > 1b) no real development would be allowed on > bf-extensions/extern/. > - BF would allow developers to make API > changes fixes and trivial > fixes on bf-extensions/extern, but not more to avoid > forking > - externals devs should agree to port these > fixes to their external repo > 2) of course only GPL-compatible scripts would be > distributable via > bf-extensions/extern/ > > > With all these resctrictions and complications, I agree > that this will > evolve into a package manager, so it's not that easy to do > it quick and > dirty. > > Our goal would be a system like the firefox addons site, > but this is a > major feature and it has has server-side maintenance > implications, so > it's not something you develop in blender only. > > > To avoid server-side implications, you should let blender > download stuff > from wherever you want but according to the discussions we > had back > then, I doubt BF will allow this on official releases. > > > Hope this has clarifies things a bit :) > > > Regards, > Luca > > > > > > > > > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited clay patch review
Hi Raul,
Please don't give up on Unlimited Clay, every blender artist i know is excited
about Unlimited Clay.
On a side note: it probably is better to have it as a modifier, at least thats
my feeling.
-brett
--- On Mon, 5/23/11, ra...@info.upr.edu.cu wrote:
> From: ra...@info.upr.edu.cu
> Subject: Re: [Bf-committers] Unlimited clay patch review
> To: "bf-blender developers"
> Date: Monday, 23 May, 2011, 12:22 PM
> Hi there :)
>
> Yes, the patch is more like spagetty code and for internal
> development, I
> use all of those hacks in order to get a working system
> first, and only
> then start reworking/redisigning into a readable form.
> UnlimitedClay is
> about mixing two very separated functionality in Blender
> source code:
> sculpting and mesh editing, and as a result I have to move
> around parts of
> the code to make them visible to other parts, that's why I
> have broken the
> encapsulation principle but I always think of that as a
> temporal solution,
> not something worth to be taken into account.
> I know everyone is busy, so do I releasing the first public
> beta or
> LiveClay for 3DCoat, UnlimitedClay now has two betas ...
> well, they're
> more like alphas ;)
> I don't expect too much aid in porting it to new sources
> rigth now, so I
> think I will have to make the migration from EditMesh to
> BMesh on my own,
> also I don't like the modifier approach but only time will
> tell whether
> is better or not to have it as an integral feature of the
> sculpting
> module or as a modifier.
>
> due to the low feedback I'm getting from unlimitedClay for
> Blender .. are
> people still interested on it? I'm still here :(
> > Hi, Blender Community!
> >
> > I've reviewed unlimited clay patch yesterday. I
> haven't been able to
> > apply patch/compile correctly, so i can't give
> feedback about how things
> > are working, but i could give some feedback about
> patch itself.
> >
> > - First of all it's created against a bit outdated
> version of trunk --
> > some files were moved, some functions renamed and so.
> It lead to plenty
> > of rejected hunks in patchs.
> > - Patch contains plenty of non-functional changes:
> whitespace changes,
> > somewhere "styling" changes, somewhere changed "logic"
> -- code in
> > non-unlimitedclay related code was replaced with
> different code whick
> > makes the same things (like normals in
> getEditMeshDerivedMesh). This
> > makes patch much more difficult to be applied against
> newer trunk and
> > readability of this patch also lower -- can't split
> what is actually
> > changes and what's not.
> > - That including of "ED_mesh.h" in DerivedMesh.c and
> pbvh.c. It's not
> > only ugly usage of absolute path. but it's also a
> breaking of
> > archeticure -- blenkernel/ and blenlib/ shouldn't use
> editors/. I
> > suppose editmesh is needed for easier changing mesh
> topology, but i also
> > suppose it could be made without such hacks. For
> example add some
> > utility functions to blenkernel/intern/mesh which
> would provide list of
> > verts/edges/faces (similar lists as in editmesh). I
> think it's the most
> > worth thing for which EditMesh is used atm.
> > - I also not sure why it's needed to move structures
> (like
> > EditMeshDerivedMesh, StrokeCache, PBVH, PBVHNode and
> so) from .c-fiels
> > into headers. This structures aren't supposed to be
> reused outside of
> > their module and they should be a blackbox for other
> modules.
> > - Styling should be checked. I'd prefer to keep only
> one style inside
> > one module. Check comments, brackets, spaces and so.
> > - Also it looks like there's some unused code adding
> by patch but which
> > isn't used.
> > - I'm not fully like all that new fields inside
> EditVert. Maybe they
> > could be moved inside tmp union or EditVert->data
> could be reused? Or as
> > i mentioned, EditMesh could be replaced by something
> more light and
> > common... Or maybe it'll be special structure for
> unlimited clay
> > purposes and functions like {make,load}_clayMesh?
> > - I'm not sure why stuff like BLI_pbvh_iter_end should
> be changed?
> >
> > That's all feedback i could give atm.
> >
> > We discussed a bit ways to split out unneeded changes
> with Tom, but not
> > sure that ways would be useful. I'd prefer if manual
> reading of patch
> > would be done -- in this case all outdated stuff would
> be found.
> >
> > I hope it'll help to make patch better and acceptable
> to be commited.
> >
> > --
> > With best regards, Sergey I. Sharybin
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
> >>>
> - Participe en Universidad 2012, del 13 al 17 de febrero de
> 2012. Habana. Cuba. http://www.congresouniversidad.cu
>
> - Consulte la Enciclopedia Colaborativa Cubana. http://www.ecured.cu
> ___
Re: [Bf-committers] Node system for game logic
The proposal at http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic is huge, great ideas, but maybe its overkill. Nodes are cool, better than what we have now, but i think "Scratch-style" logic blocks would be simple and even more clear. http://scratch.mit.edu/ One issue i see is there are many changes at the C level that need to be made to leverage the current node interface. Why not take a pure python approach, and use ctypes where needed? If the UI is going to be general and compatible with other engines like Panada3d, etc.. it really should use a standard GUI toolkit like Qt or Gtk. -brett --- On Sat, 5/28/11, Benoit Bolsee wrote: > From: Benoit Bolsee > Subject: Re: [Bf-committers] Node system for game logic > To: bf-committers@blender.org > Date: Saturday, 28 May, 2011, 9:49 AM > Hi Sjoerd, > > Thanks for sharing the hive system. I've started to read > the > documentation and so far I'm impressed by what you have > done. I already > have a good idea of the system but I still have to figure > out how you > have achieved all the goals that I stated in my proposal. > At some point > I will contact you when I know enough to not waste your > time with stupid > questions. > > As far as licensing is concerned, I would prefer if you go > to a > BSD-style license but you should in any case take a firm > and definitive > position quickly to cut short what seems to be an endless > discussion on > licensing again ;-) > > Regards, > Benoit > > > > > Message: 1 > > Date: Thu, 26 May 2011 14:55:19 +0200 > > From: Sjoerd de Vries > > Subject: [Bf-committers] Node system for game logic > > To: bf-committers@blender.org > > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Hi everyone, > > > > I would like to present to you the hive system, a > working > > node system for game logic (and other things). > > > > It implements the complete list of goals of Benoit's > Nodal > > Logic proposal: > > http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic > > Some of the design decisions are different, but the > hive > > system contains all of his features. > > > > The source code is available under GPL: > > > > http://launchpad.net/hivesystem > > > > It also has a GUI for editing hivemaps (node graphs). > It is > > basic and quirky but it works. This makes it possible > for > > non-programmers to create and modify game logic. I > have made > > a screencast that demonstrates this for a simple 3D > scene: > > > > http://launchpad.net/hivesystem/trunk/0.7/+download/screencast.swf > > > > New nodes and hives can easily be built in Python. > However, > > the coding style is different from normal Python > scripts. I > > have written a long manual with many examples. If > anything is > > unclear, please tell me. > > > > The main limitation is that there are no bindings yet > to the > > BGE, only to Panda3D. It still needs to be ported to > > Python3.2, and I am not very familiar with the BGE > source > > code. Also, a lot of important nodes (sound, physics, > mouse > > picking, networking) are still missing. > > > > I am looking forward to join forces with Benoit and > Sven, and > > with anyone else who is interested. Any feedback is > welcome! > > > > cheers > > > > Sjoerd > > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] AttributeError: Writing to ID classes in this context is not allowed
I understand not allowing properties on an object to be changed when in the "draw" method of a bpy.types.Panel forces good coding practices for addon developers. I think its a good idea to have this rule. I wish there was a way to bend this rule sometimes. There are a few cases where it would really come in handy, and doing some other way using Operators can make the code boated and clumsy. Here is my example: in the blender2ogre exporter, i have a tool panel for managing collisions that makes a duplicate object with a decimate modifier. When the user enables or disables the collision, the collision object should be hidden or shown, but right now its not allowed to change the hide property on the collision object throwing the error: AttributeError: Writing to ID classes in this context is not allowed Any way we can bend this rule? -brett ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
Maybe this is an option; having the audio playback as the main time keeper, and then dropping frames in the view-port if they fail to render within time (within frame accuracy). But one problem is for a heavy scene this could mean that no frames are ever rendered in time and all are dropped, a work around could be: measure the average delay it takes to render a frame and skip ahead to rendering the next frame by that delay. -brett --- On Sun, 7/17/11, Martin Poirier wrote: > From: Martin Poirier > Subject: Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC > To: "bf-blender developers" > Date: Sunday, 17 July, 2011, 2:37 PM > Hi, > > I'd like to ask people with good knowledge of Blender's > animation and animation related structures to please > consider this problem, this is rather important for neXyon's > GSOC project. > > Thanks, > Martin > > --- On Sun, 7/17/11, neXyon > wrote: > > > From: neXyon > > Subject: [Bf-committers] Help needed! Animation > problems for 3D Audio GSoC > > To: bf-committers@blender.org > > Received: Sunday, July 17, 2011, 2:31 AM > > Hi guys! > > > > There's a serious problem with the way how animation > works > > in regard to > > audio. The main problem is, that the animation system > > pushes the output, > > so it sets the data, renders a frame, advances to > next > > frame (setting > > the data there) and renders again and so on, this > works > > pretty good for > > video. But it doesn't work with audio, especially as > audio > > has a very > > high temporal resolution (48000 eg. samples per > second) > > compared to > > video (eg 25 frames per second) and moreover for audio > the > > output device > > pulls the data, instead of the animation system > pushing it, > > so the other > > way round. > > > > I talked to Martin (Poirier) and Joshua (Leung) and > even we > > three > > together cannot think up a nice solution for the > problem, > > maybe some > > genious mind here on the list who is more into the > > animation code than I > > am has a really nice idea. > > > > Here are specific problems in detail: > > > > * Subsample Accuracy: To avoid stair steps as we > currently > > have in > > volume animation. > > * Multi Threading: Audio runs in a separate thread. > > * Speed: The access mechanism has to be realtime > capable! > > * Asynchronous access: Audio playback is ahead of > video > > playback > > normally (buffering the samples, feeding them to the > output > > device). > > > > The first point can be solved easily with a proper > > interpolation if you > > have two nearby samples, one in the past, one in the > > future, so this > > basically requires the animation data to be > cached/buffered > > somehow or > > at least asynchronous accessible. As the cached data > also > > solves points > > 3 and 4 it's pretty obvious that we need the data > cached, > > we had that > > conclusion already. > > > > Questionable is now how to get the cache? One obvious > > solution is to > > require the user to "bake" it, but this heavily > impacts how > > easy the > > system can be used and as we also already concluded > this is > > a really > > ugly solution. Better is the automatic caching which > leads > > us to the > > problem point 2 multi threading. I don't know if it's > > possible to cache > > in the main thread? I bet not. And as long as > blenders > > (animation) data > > isn't accessible multithreaded we still have no > solution > > for the problem. > > > > So now your help is needed. Any ideas? If not I'll > have to > > do the baking > > solution to finish the project. > > > > Regards > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] MinGW builds available?
Im looking for MinGW builds on graphicall but everybody is using MS-express2008. I need a 32bit Windows MinGW build, are there any out there for download? -brett- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] UI for dnd textures, works on linux, ctypes-GTK3
http://www.youtube.com/watch?v=1QFuTy3ZoCM source code at: http://code.google.com/p/pyppet/source/list ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Introducing "Multi-touch Blender3D"
Greetings Blender Devs, A new kickstarter project is just underway with the goal to optimize blender for multi-touch tablets. However, the project also has some goals beyond simply porting to multi-touch devices including: 1. motion capture, and 2. simplified interface for younger kids. First, motion capture with off-the-shelf-hardware could be a unique selling point for blender, a muti-touch device is already a good device for digital puppetry, so why not support other hardware like the Kinect, and SonyMove. This 3-way combination packs a very powerful punch, where the limitations of each device can cancel each other out to provide very responsive motion capture. Second, there is no reason why blender can not have an interface for pros that is fast and powerful while at the same time simplifying it for younger kids. Currently i have seen dedicated 13 year olds teach themselves blender. If the UI contained two modes (expert, kid) or became more modal, then kids younger than 13 should be able to grasp it. What i think will attract these younger kids is the motion capture possiblities. Perhaps younger kids can not master modeling or rigging - but lets say their 15 year older brother already has; and then this hypothetical family can have fun and collaborate together in creating an animation. As far as timeline, one year is really just a guess, could be plus or minus 6 months. The kickstarter budget is minimal but enough for me, i know how to stretch that little money for even longer if needed; if the kickstarter goes over 100% funding, of course more buffering is ideal. Kickstarter recommends not asking for too much money, and i agree with them. Please visit: http://www.kickstarter.com/projects/hartshorn/multi-touch-blender3d -brett ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Reqesting: hidden custom-properties on texture-slots
I am working on the Ogre exporter for blender25. The issue i am having is with fully supporting all of Ogre's texture-unit options, right now i store some options at the material level, others at the texture level, and still others by hijacking rarely used options in texture-slots. Some options of texture-slot objects can be directly mapped to an Ogre texture unit, others can not. This problem could easily be solved with custom property (IDProperty) support for material slots, then i can attach any data i need to the texture-slot objects and not have to over-ride existing options.This feature may be useful for other exporters as well. -brett ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Possibility to create custom color-ramp properties / UI
Custom Properties (IDProperties) could do the job if more objects supported them. But right now you can only do custom properties on Mesh, Object, Material, Texture. You can not do custom props on Texture slots, shader nodes and other places where it would be useful. I have the same problem supporting all the possible options for the Ogre exporter.-brett --- On Sat, 12/11/10, Doug Hammond wrote: From: Doug Hammond Subject: [Bf-committers] Possibility to create custom color-ramp properties / UI To: "bf-blender developers" Date: Saturday, 11 December, 2010, 7:09 AM Hi, I'd like to know if this is somehow possible, or if it can be made possible in the future. LuxRender recently gained a 'band' texture which would require this interface to implement properly. At the minute our implementation options in the exporter/addon are few. Regards, Doug. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting, sunday 12 dec, 2010
A font with good unicode coverage would be nice to have. --- On Sun, 12/12/10, Ton Roosendaal wrote: From: Ton Roosendaal Subject: [Bf-committers] Blender developer meeting, sunday 12 dec, 2010 To: "bf-blender developers" Cc: edit...@blendernation.com Date: Sunday, 12 December, 2010, 8:52 AM Hi all, 1) projects.blender.org - Trackers and projects.blender.org migrated - We had some bad luck with a server hanging, but that's solved now. - todo: SCM viewer for browsing svn history. Will come back early january (?) (tip: use svn annotate for checking files) - todo: searching for open reports assigned to specific person Issues for the trackers or website can be posted here: http://projects.blender.org/tracker/index.php?group_id=8&atid=121 2) 2.5 issues - Time for a new official beta! Proposal: announce on 26th, release midweek after. Question: are release builders available in this holiday season? - Ton will now for real work on the official regression test update! A version of it should be in the GSoX unit-test project. - Dalai proposes to replace the ancient built-in vector font with a more modern (and official free) one. We can even include a couple? Waiting for proposal... - Work on UI "Style" system is a todo, and will allow loading own font sets, and assign to UI items like panels, menus, buttons, labels. - Tracker work (bug fixing) goes excellent. We're getting more time to move attention to the long todo in wiki.blender.org now. 3) Other projects - Francesco Siddi is working on the WP theme and layout for code.blender.org. Estimated release is this week! -Ton- Ton Roosendaal Blender foundation ...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] pixel get & image processing - update?
http://lists.blender.org/pipermail/bf-committers/2010-April/027213.html what happened to get_pixel for python? raw buffer access would be nice to. -brett ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Getting pixel color for a vertex (the stupid way)
Getting a UV texture's pixel value per vertex, the stupid way. (this should be rewritten as a C function exposed to Python) This script does the following hack to get the pixel value: 1. copy the object 2. apply a displace modifier 3. for each RGB set the ImageTexture._factor to 1.0 and others to 0.0 4. for each RGB bake a mesh (apply the displace modifier) 5. for each RGB find the difference of vertex locations 6. apply the differences as vertex colors http://pastebin.com/FJWKSGBR for some reason the values are off and always tinted green. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Getting pixel color for a vertex (the stupid way)
Daniel raises a good point here, and i'm sure there are others who need the functionality. There is another problem, lets imagine that even if PIL was available for Python3, then the user must install Python3, and PIL - what a pain and error prone process. And not very portable either since Ubuntu is going to come with its own version of Python3 that may not be compatible with whatever version blender was compiled with. The solution seems to be ctypes, and for some basic commonly used libs (like libpng for example) to be precompiled for all platforms, and distributed right along with blender by default. The ctypes python wrappers themselves do not need to be included with blender as those are likely to rapidly evolve over time, but the precompiled libs should be included - why not it will hardly inflate the download size? Scripters should not have to ship their scripts with libs compiled for every platform. It should be pretty easy to add a few extra libs to the cmake build process, i'm sure there is already so many libs that blender already uses that could be exposed by ctypes. -brett --- On Tue, 12/14/10, Daniel Salazar - 3Developer.com wrote: From: Daniel Salazar - 3Developer.com Subject: Re: [Bf-committers] Getting pixel color for a vertex (the stupid way) To: "bf-blender developers" Date: Tuesday, 14 December, 2010, 11:30 PM Damn... this is bad, specially since Python 3 has no image module (PIL), there's just no way.. unless you pick a simple format like a BMP and read the data straight from file.. still procedurals would be left out. Also the Fracture Tools script need access to texture values for cracking objects based on textures and I have needed it personally. I hope this gets fixored Daniel Salazar www.3developer.com On Wed, Dec 15, 2010 at 1:19 AM, Hart's Antler wrote: > Getting a UV texture's pixel value per vertex, the stupid way. > (this should be rewritten as a C function exposed to Python) > This script does the following hack to get the pixel value: > 1. copy the object > 2. apply a displace modifier > 3. for each RGB set the ImageTexture._factor to 1.0 and others to 0.0 > 4. for each RGB bake a mesh (apply the displace modifier) > 5. for each RGB find the difference of vertex locations > 6. apply the differences as vertex colors > > http://pastebin.com/FJWKSGBR > > for some reason the values are off and always tinted green. > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A proposal for further 2.5x UI evolution
I agree with the statement "Key koncept: no visual searching if possible.", but i think the way to do it is with color coding. Why can't these panels have a color tinting? Then the user can simply see from the corner of their eye which panel is which without even reading anything.-brett --- On Thu, 12/16/10, Troy Sobotka wrote: From: Troy Sobotka Subject: Re: [Bf-committers] A proposal for further 2.5x UI evolution To: "bf-blender developers" Date: Thursday, 16 December, 2010, 2:22 PM On Thu, Dec 16, 2010 at 11:31 AM, Vilem Novak wrote: > Hello, > I put together a proposal for some further possible changes in the 2.5x UI. I cannot comment on some of the more modelling centric elements, as I don't have much experience with them to comment. Specifically however, I found two elements of your discussion interesting: > "mixed panel order" Panels need to be adjusted based upon artist workflow and area of expertise. When you fix panel locations, you are forcing an artistic workflow without knowing what exactly the given artist is seeking to achieve. Compositing, modelling, rendering looks, rigging, etc. are all _radically_ different workflows that will prioritize different panels over others. An advanced artists tool such as Blender makes no assumptions about workflows or artist needs and allows the artists to make these fundamental adjustments. > "uneven height of a panel stack" > is less bad as previous, but still adds a lot to "searching time" Scanning is something that pertains to a very specific audience segment, in particular, new and hobby individuals that likely won't be spending much time with an application. Sacrificing in the name of this segment is questionable given the nature of the application. > "not foldable(who > DOESN'T want to see what he's actually doing? Here you are making an assumption that you know what the artist is doing or attempting to do. It is the same sort of small assumption that leads one reading your sentence to imply an assumed male artist. Again, not all panels relate to a given workflow or set of tasks. Being able to customize those panels to suit the workflows is absolutely mandatory. This is something that the Blender interface design has taken into account and has delivered. The changes listed seem to be rooted in a distinct lack of screen real estate, something that again Blender makes no assumptions about. Making dubious changes as suggested would intrinsically crippled Blender's ability to deal with large display workspace formats. Sincerely, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Custom Properties - python issues
1. KeyError: 'the length of IDProperty names is limited to 31
characters'object['x'*32] = 'why not make the limit 32 or 64?, 31 is an odd
number - not possible to use md5sum hashes either as a workaround'
2. inner single quotes are invalid## this failslayout.prop( object,
"['my-custom-prop']" ) # a better warning should be printed, or
single quotes should be supported## this works - double quotes must be
usedlayout.prop( object, '["my-custom-prop"]' )
3. dicts are allowed, but layout.prop(...) can not show each subkey on its
own## (the dict can be viewed as a string from Custom Properties Panel, but
thats not very useful for the user) ##object['x'] = {'a':1, 'b':2}box.prop(
object, '["x"]["a"]' ) # error: rna_uiItemR: property not found:
Object.["x"]["a"]box.prop( object, '["x"]' ) # this also fails
4. booleans not supported by custom propertiesobject['my-custom-prop'] = True
# converted to 1 without any warninglayout.prop( object,
'["my-custom-prop"]', toggle=True )# toggle is ignored, numeric entry is
displayed instead
## workaround ##class mypanel(bpy.types.Panel): bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW' bl_context = "object" bl_label = "toggle
custom prop example" @classmethoddef poll(cls, context): return True
def draw(self, context):layout = self.layoutob =
context.active_object tag = 'my-custom-prop' if tag not
in ob.keys(): ob[tag] = True v = ob[tag] if v: icon =
'CHECKBOX_HLT' else: icon = 'CHECKBOX_DEHLT' op =
layout.operator( 'toggle_prop', text=tag, icon=icon ) op.propname
= tag
class toggle_prop_op(bpy.types.Operator): '''operator:
prop toggle helper''' bl_idname = "toggle_prop" bl_label = "toggle"
bl_options = {'REGISTER', 'UNDO'} propname =
StringProperty(name="property name", description="...", maxlen=32, default="")
@classmethoddef poll(cls, context): return True def invoke(self,
context, event): ob = context.active_object ob[
self.propname ] = not ob[ self.propname ] return {'FINISHED'}
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] blender25 and ctypes-pygtk
I managed to get GTK to work pretty well with blender25 using ctypes. The old PyGTK bindings didn't work that well with blender2.4x because the GTK mainloop did not release the GIL, and there was no ideal way to iterate the main loop from blender. Thankfully ctypes releases the GIL, so threading works! Not sure if updating blender data from a GTK thread can cause a crash, but with this simple addon that changes the scale of the selected object everything is ok so far.more details and source code here:http://pyppet.blogspot.com/2011/01/ctypes-pygtk-in-blender25.html -brett ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] blender job market
The recent blog post by Farsthary got me thinking, why is one of the best blender developers out there hard up for money? A quick look at the blender job market reveals it is almost non-existent compared to the Maya or 3dsMax job market. This leads to the next question: with blender's recent advancements why is there so little adoption by studios? I think the fundamental issue holding up adoption is blender currently offers no viable migration path for studios, its either switch or don't use - so they don't use it. A migration path requires integration with proprietary tools and Maya and other commercial software. Studios typically employ many programmers to create in-house tools and glue code, and this reflected by the large job market for MEL scripters and developers using the Maya C++ API. My point is that: before studio artists can start using blender, the studio programmers must also be able to use, extend, and integrate blender into the pipeline. Blender is currently not easy to integrate within other tools. The Python API has its limitations, and the C API does not offically exist. To make integration simple, what is needed is a stable C API and a blender library (libblender.dll) that can be dynamically loaded by any program and then used to call any function within blender. Lets imagine a studio might be interested in first using the unlimited clay features from within Maya - in theory a modular blender library makes this possible. This is the beginning of their migration path, and over time they can integrate more blender features into their pipeline - in the end they can make a complete switch if they choose. Running blender inside Maya also solves the problem that blender can not load or save a maya binary file; the fact is studios have their data locked up in .mb and .max files; and they are not going to throw away compatibility with their old data. Blender has come a long way, and one could argue its more powerful than commercial offerings in several ways. It should now be at the tipping point for studio adoption, if only this final integration road-block is lifted. -brett ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] pixel get & image processing
Very interesting Ideasman,is this the secret back door for getting into blender
from ctypes? Passing empty strings returns blenders internals, just like when
ctypes normally loads an external shared library?
blend_cdll = ctypes.CDLL("") blend_lib = ctypes.LibraryLoader("")
-brett
--- On Wed, 1/26/11, Campbell Barton wrote:
From: Campbell Barton
Subject: Re: [Bf-committers] pixel get & image processing
To: dom...@dominodesigns.info, "bf-blender developers"
Date: Wednesday, 26 January, 2011, 8:33 PM
Adding image access properly is tricky because it needs to work right
with blender, notify on changes, upload rect from float, lock the
image threads before accessing.
I had a talk to Ton about this but he's of the opinion to support it
correctly or not at all (which is understandable).
But, I get the impression python devs work on specific projects where
image access is useful (research & custom scripts) so I wrote a
ctypes (pure python) direct memory access to pixel data for people who
like to experement with this.
a quick test on setting all pixels on a 1024x1024 image though python
took 0.75 seconds, getting was about the same.
Is someone wants to extend this further they could add 'py_buffer'
access to bypass pythons slowness.
Note that this is totally unsupported, The script is 30 lines added to
the bottom of pydna.py which adds "buffer_raw" attribute to existing
image objects.
Download:
http://www.graphicall.org/ftp/ideasman42/image_buffer_raw_access.py
Example usage.
>>> # Inserts property into blenders Image RNA.
>>> import image_buffer_raw_access
>>>
>>> ima = bpy.data.images['MyImage']
>>> x, y, rect, rect_float = ima.buffer_raw
>>> pixel_index_max = x * y * 4
>>> # set colors for first pixel
>>> rect[0] = 0 # red
>>> rect[1] = 255 # green
>>> rect[2] = 128 # blue
>>> rect[3] = 255 # alpha
On Tue, Jan 25, 2011 at 11:55 PM, Domino Marama
wrote:
> On Tue, 2011-01-25 at 15:44 -0700, Dan Eicher wrote:
>
>> Anyhoo, image data access comes up quite often and the party line it
>> seems is to just use ctypes (which doesn't work for our windows
>> brethren due to the way msvc exports symbols). Or there's an
>> 'unofficial' port of PIL to py3 that works according to Josh (from the
>> Tube project) blog but I haven't tested it yet meself.
>
> I've got to say that the continued lack of any official way to
> manipulate and read images from python is a show stopper for me and a
> large number of users of my Primstar scripts for Second Life sculpties.
>
> One of my users offers paid support for my scripts and I know they get
> hundreds of new customers each month. The active user base is well into
> the thousands, and we are all still using Blender 2.49 :)
>
> I've users on Windows version from XP upwards, various Linux distros and
> even Mac users willing to put up with UI bugs caused by my use of
> tkinter dialogues.
>
> I'm not interested in rewriting Primstar in C, some of the features
> would be too complex to implement as I make extensive use of variable
> length lists per pixel during the bake process to provide unrivalled
> flexibility in sculptie creation. I also couldn't support all the
> platforms I currently do with Python.
>
> Hopefully the mission to move all users to 2.5.x will outweigh the
> issues in allowing image editing in Python soon as there's a lot of us
> waiting for the scales to tip ;)
>
> Something like the RenderLayer.rect access would be great, but I'd
> settle for get_rect and set_rect if live access is too slow on a pixel
> basis. Though "too slow" is better than "not possible" in my book
> anyway..
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] pixel get & image processing
So basically, the best way to expose the blender C API and its data structures,
is to parse all the headers in blender? and generate a ctypes bindings for
everything?-brett
--- On Wed, 1/26/11, Campbell Barton wrote:
From: Campbell Barton
Subject: Re: [Bf-committers] pixel get & image processing
To: "bf-blender developers"
Date: Wednesday, 26 January, 2011, 11:11 PM
Blank strings to these functions use the current process.
Typically ctypes is not all that useful for data access with large C
programs because you need to match the ctypes class with the C headers
(involves parsing headers or manual copying).
ctypes.CDLL("") / ctypes.LibraryLoader("") are only used to extract
the DNA struct info blender stores internally for blend file reading.
Its possible to read the image buffer with a much smaller script if
the 'Image' struct was hard coded into it, but when writing pydna.py I
was more interested in a way to wrap all DNA, not image access,
advantage with this method is Image struct changes wont break. Any
changes to the ImBuf struct will break since ImBuf is not a DNA
struct, it cant be auto-wrapped.
Disclaimer that pydna.py is 'use at own risk', experimental, unsupported by BF.
- Campbell
On Thu, Jan 27, 2011 at 6:41 AM, Hart's Antler wrote:
> Very interesting Ideasman,is this the secret back door for getting into
> blender from ctypes? Passing empty strings returns blenders internals, just
> like when ctypes normally loads an external shared library?
> blend_cdll = ctypes.CDLL("") blend_lib = ctypes.LibraryLoader("")
> -brett
> --- On Wed, 1/26/11, Campbell Barton wrote:
>
> From: Campbell Barton
> Subject: Re: [Bf-committers] pixel get & image processing
> To: dom...@dominodesigns.info, "bf-blender developers"
>
> Date: Wednesday, 26 January, 2011, 8:33 PM
>
> Adding image access properly is tricky because it needs to work right
> with blender, notify on changes, upload rect from float, lock the
> image threads before accessing.
>
> I had a talk to Ton about this but he's of the opinion to support it
> correctly or not at all (which is understandable).
>
> But, I get the impression python devs work on specific projects where
> image access is useful (research & custom scripts) so I wrote a
> ctypes (pure python) direct memory access to pixel data for people who
> like to experement with this.
>
> a quick test on setting all pixels on a 1024x1024 image though python
> took 0.75 seconds, getting was about the same.
>
> Is someone wants to extend this further they could add 'py_buffer'
> access to bypass pythons slowness.
>
> Note that this is totally unsupported, The script is 30 lines added to
> the bottom of pydna.py which adds "buffer_raw" attribute to existing
> image objects.
>
> Download:
> http://www.graphicall.org/ftp/ideasman42/image_buffer_raw_access.py
>
> Example usage.
>>>> # Inserts property into blenders Image RNA.
>>>> import image_buffer_raw_access
>>>>
>>>> ima = bpy.data.images['MyImage']
>>>> x, y, rect, rect_float = ima.buffer_raw
>>>> pixel_index_max = x * y * 4
>>>> # set colors for first pixel
>>>> rect[0] = 0 # red
>>>> rect[1] = 255 # green
>>>> rect[2] = 128 # blue
>>>> rect[3] = 255 # alpha
>
>
> On Tue, Jan 25, 2011 at 11:55 PM, Domino Marama
> wrote:
>> On Tue, 2011-01-25 at 15:44 -0700, Dan Eicher wrote:
>>
>>> Anyhoo, image data access comes up quite often and the party line it
>>> seems is to just use ctypes (which doesn't work for our windows
>>> brethren due to the way msvc exports symbols). Or there's an
>>> 'unofficial' port of PIL to py3 that works according to Josh (from the
>>> Tube project) blog but I haven't tested it yet meself.
>>
>> I've got to say that the continued lack of any official way to
>> manipulate and read images from python is a show stopper for me and a
>> large number of users of my Primstar scripts for Second Life sculpties.
>>
>> One of my users offers paid support for my scripts and I know they get
>> hundreds of new customers each month. The active user base is well into
>> the thousands, and we are all still using Blender 2.49 :)
>>
>> I've users on Windows version from XP upwards, various Linux distros and
>> even Mac users willing to put up with UI bugs caused by my use of
>> tkinter dialogues.
>>
>> I'm not interested in rewriting Primstar in C, some of the features
>> would be too complex to implement as I make extensive use of vari
Re: [Bf-committers] pixel get & image processing
pybindgen won't do ctypes, thats part of the reason why i wrote RPythonic - it
will do ctypes or RFFI. With RFFI compiled python can talk to C, if you need
maximum speed.http://code.google.com/p/rpythonic/
--- On Thu, 1/27/11, Campbell Barton wrote:
From: Campbell Barton
Subject: Re: [Bf-committers] pixel get & image processing
To: "bf-blender developers"
Date: Thursday, 27 January, 2011, 12:42 PM
Yes, the problem is you need to have headers from the same version of
blender used to get the offsets, that runs the python scripts.
This would work best if it was a part of the blender build process
though its not at all likely to happen since we already have RNA.
You may be interested in: http://code.google.com/p/pybindgen/
On Thu, Jan 27, 2011 at 9:02 AM, Hart's Antler wrote:
> So basically, the best way to expose the blender C API and its data
> structures, is to parse all the headers in blender? and generate a ctypes
> bindings for everything?-brett
>
> --- On Wed, 1/26/11, Campbell Barton wrote:
>
> From: Campbell Barton
> Subject: Re: [Bf-committers] pixel get & image processing
> To: "bf-blender developers"
> Date: Wednesday, 26 January, 2011, 11:11 PM
>
> Blank strings to these functions use the current process.
> Typically ctypes is not all that useful for data access with large C
> programs because you need to match the ctypes class with the C headers
> (involves parsing headers or manual copying).
>
> ctypes.CDLL("") / ctypes.LibraryLoader("") are only used to extract
> the DNA struct info blender stores internally for blend file reading.
>
> Its possible to read the image buffer with a much smaller script if
> the 'Image' struct was hard coded into it, but when writing pydna.py I
> was more interested in a way to wrap all DNA, not image access,
> advantage with this method is Image struct changes wont break. Any
> changes to the ImBuf struct will break since ImBuf is not a DNA
> struct, it cant be auto-wrapped.
>
> Disclaimer that pydna.py is 'use at own risk', experimental, unsupported by
> BF.
>
> - Campbell
>
> On Thu, Jan 27, 2011 at 6:41 AM, Hart's Antler wrote:
>> Very interesting Ideasman,is this the secret back door for getting into
>> blender from ctypes? Passing empty strings returns blenders internals, just
>> like when ctypes normally loads an external shared library?
>> blend_cdll = ctypes.CDLL("") blend_lib = ctypes.LibraryLoader("")
>> -brett
>> --- On Wed, 1/26/11, Campbell Barton wrote:
>>
>> From: Campbell Barton
>> Subject: Re: [Bf-committers] pixel get & image processing
>> To: dom...@dominodesigns.info, "bf-blender developers"
>>
>> Date: Wednesday, 26 January, 2011, 8:33 PM
>>
>> Adding image access properly is tricky because it needs to work right
>> with blender, notify on changes, upload rect from float, lock the
>> image threads before accessing.
>>
>> I had a talk to Ton about this but he's of the opinion to support it
>> correctly or not at all (which is understandable).
>>
>> But, I get the impression python devs work on specific projects where
>> image access is useful (research & custom scripts) so I wrote a
>> ctypes (pure python) direct memory access to pixel data for people who
>> like to experement with this.
>>
>> a quick test on setting all pixels on a 1024x1024 image though python
>> took 0.75 seconds, getting was about the same.
>>
>> Is someone wants to extend this further they could add 'py_buffer'
>> access to bypass pythons slowness.
>>
>> Note that this is totally unsupported, The script is 30 lines added to
>> the bottom of pydna.py which adds "buffer_raw" attribute to existing
>> image objects.
>>
>> Download:
>> http://www.graphicall.org/ftp/ideasman42/image_buffer_raw_access.py
>>
>> Example usage.
>>>>> # Inserts property into blenders Image RNA.
>>>>> import image_buffer_raw_access
>>>>>
>>>>> ima = bpy.data.images['MyImage']
>>>>> x, y, rect, rect_float = ima.buffer_raw
>>>>> pixel_index_max = x * y * 4
>>>>> # set colors for first pixel
>>>>> rect[0] = 0 # red
>>>>> rect[1] = 255 # green
>>>>> rect[2] = 128 # blue
>>>>> rect[3] = 255 # alpha
>>
>>
>> On Tue, Jan 25, 2011 at 11:55 PM, Domino Marama
>> wrote:
>>> On Tue, 2011-01-25 at 15:44 -0700, Dan Eicher wrote:
>>>
>>>> Anyhoo, image data access comes up quite oft
Re: [Bf-committers] A big problem with python 3.2
+1 for py3.1 compatible If the only incompatibly with blender 3.1 is that libpython3.so becomes libpython3du.so its easy to fix with an ifdef macro. or are scripts already using functionality from 3.2 and we must have it? -brett --- On Tue, 3/8/11, Dave Plater wrote: > From: Dave Plater > Subject: [Bf-committers] A big problem with python 3.2 > To: bf-committers@blender.org > Date: Tuesday, 8 March, 2011, 4:33 AM > I've now found that blender no longer > builds with python 3.1 at all. > This creates a problem that the latest blender is in the > graphics devel > project and python 3.2 is in devel:languages:python:Factory > so in order > to install blender the user also has to enable the > devel:languages:python:Factory repository because that is > the only place > it is available, the just released 11.4 still has python > 3.1 which from > what I have read is the same in Ubuntu, Fedora and most > probably Mandriva. > Please can blender be made to build with python 3.1 again. > > Thanks > Dave P > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
