The sign of a good developer is always in what they finish, not necessarily what they start. 
That said, Nicholas is one of the last ones to use this adage against, given his effort & contribution to Blender !!!
The big problem to solve is performance, which halted Farstahy whoās now waiting for bmesh integration before working furtherā¦
Funny how BMesh keeps doing that. :mad:
Yes, but a lot of Nicholasā stuff is ānot in trunkā because of the feature freeze (and now bit-rot) rather than from not being āfinishedāā¦ Although finished is always a relative term with this sort of thingā¦ Ptex support implemented in the vertex paint module means you donāt have vertex paint anymore! so should it be āptex modeā and keep the old āvertex paintā mode? the feature itself is complete in that it can be edited, rendered etc and the improvements to brush handling are astounding!
On the mailing list there were plenty of suggestions for Farstahy to finish unlimited clay by writing his own acceleration structuresā¦that was part of the thinking to make it a modifier. I get the feeling that making a dependancy on bmesh is more a choice in this case than an actual roadblockā¦
Hope all the stuff heās demostrated in his videos will be merged into 2.6.
Everything heās developed is amazing, and extremely useful.
Perhaps that speaks more to the Blender development process than Nicholas then
Although finished is always a relative term with this sort of thingā¦ Ptex support implemented in the vertex paint module means you donāt have vertex paint anymore! so should it be āptex modeā and keep the old āvertex paintā mode? the feature itself is complete in that it can be edited, rendered etc and the improvements to brush handling are astounding!
See, the brush improvements are something I hadnāt heard of and (if the odds play out as they have in the past) may never see. What did he do to improve them? I have been trying recently to paint inside Blender andā¦ well, itās not the best tool in my toolbox.
On PTex itself, as long as I can transfer to/from standard UV layouts and textures (game developer here), Iād be happy to see it merged into trunk. That said, also due to game developer background, not being able to paint vertices is going to make me (& others) somewhat grumpy. It is a standard mechanism nowadays for altering grime, specularity, etc across tiled surfaces (like walls, floors, paths, etc).
On the mailing list there were plenty of suggestions for Farstahy to finish unlimited clay by writing his own acceleration structuresā¦that was part of the thinking to make it a modifier. I get the feeling that making a dependancy on bmesh is more a choice in this case than an actual roadblockā¦
Either way, the delay in BMesh is affecting things. After the time it has taken and the features that have been omitted in the current version (even mentioned at SIGGRAPH) because of it, itās getting hard to defend the process around the dev of BMesh now. Yes, I feel sympathy for the guy but it doesnāt change the fact BMesh is holding back Blender in some significant areas now.
Howardt is putting in some good fixes for bmesh, and has added all the todos into the code as comments ready for triage with campbellā¦ so good progress there.
Nicholas work in ptex with brushes included all the texure options from sculpt mode, eg drag dot, anchored, rake etc, so you can make more powerful custom brushes. Better use of textures as brushes with sensible conversion to alphaā¦ and the amazingly useful texture overlay for moving and rotating textures to paint through like a stencil over the viewportā¦
JWilkins is doing some work with all of Nicholas 2010 stuff in his gsoc this yearā¦ as well as expanding by adding mypaint brush support and unifying all the paint modesā¦ Recent onion builds are currently a regression, but my hopes are high that he can finish this and get everything ready for mergeā¦ officially gsoc finishes soon though!
Isnāt ptex held back partly because itās not supported by the render engine? A job that might be more suitable for some with more in-depth knowledge about the render engine. Also since Brecht is rewriting the shading pipeline there is really no point in starting that work right now.
Meanwhile the behavior of existing sculpting tools isnāt great. The most important! Not a tool close to artistās needs.
and the amazingly useful texture overlay for moving and rotating textures to paint through like a stencil over the viewportā¦
This would certainly rock.
Not the point I was makingā¦ but that said, this is not the thread for said point. So Iāll shut-up about it
Nicholas work in ptex with brushes included all the texure options from sculpt mode, eg drag dot, anchored, rake etc, so you can make more powerful custom brushes. Better use of textures as brushes with sensible conversion to alphaā¦ and the amazingly useful texture overlay for moving and rotating textures to paint through like a stencil over the viewportā¦
OK, those are indeed very good features that Blender would be well-enhanced by including. Iāve actually been after the stencil feature for Blender stuff and, whilst I love ZBrush to death (it seriously is a great piece of software), I cannot afford to keep updating it!
Perhaps the blame for ānot finishingā stuff should be put on the management of Blender development? Again, not a discussion for this thread though.
JWilkins is doing some work with all of Nicholas 2010 stuff in his gsoc this yearā¦ as well as expanding by adding mypaint brush support and unifying all the paint modesā¦ Recent onion builds are currently a regression, but my hopes are high that he can finish this and get everything ready for mergeā¦ officially gsoc finishes soon though!
Well, whilst skirting the edge of off-topic again, I think this would depend on the focus of the core Blender developers. I get the scary feeling that, with the start of Mango only a few months off, that features not fitting the needs of that might again be dropped by the wayside. As any coder knows, the longer patches sit outside the main development trunk of a project, the less likely they are ever to be included. Bit-rot sets in and over time the impression builds that it would take longer to merge it than it would to develop from scratch (depending on how changed the code-base gets - this can actually be the case!).
Looking forward to seeing a few of the things coming from GSOC into the main branch. At the very least, the match-moving and retargeting stuff looks like it might get focus, if only because their use in Mango seems a given 
Off Topic: But, I donāt understandā¦ when did zBrush start charging for updates?
Off topic continuationā¦ sorry guysā¦:o
If you have a legitimate copy of Zbrush, regardless of version, just send them your registration details that you purchased the program under. https://support.pixologic.com/. This is one of the biggest surprises for a program such as zbrush is that no one has needed to purchase an update till now. Please see this from their own support forum.
https://support.pixologic.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=43&nav=0,12
Though things can change at anytime. Taken from their forum.
ZBrush 4R2 will be released for both Win & Mac on 9/20/11! (September [COLOR=Silver]20th, 2011[/COLOR]) .
All registered users of the current version, including those who purchase between now and the release of ZBrush4R2, will receive the new version as a free upgrade.
So better get version 4 registered before things changeā¦ possibly
That is the one thing I really really dislike about Blender. The fact that it doesnāt have a plugin based approach like a lot of other modern products and extending blender always seems to result in a new branch. Python scripts are fun but there is also a limitation in what it can do.
I lost count how many branches are sitting in my Blender folder.
I disagree that Blender is less extendable than other a lot from commercial products. The difference you see is only because 3rd party developers have to take detours to implement certain functionality since the source is closed. You can do many of these thing in Blender too but the open source makes it redundant. Also due to the transparent development in open source youāll see features long before theyāre completed, I bet Autodesk & co uses branches in their development too but you wonāt see them before theyāre included in a official release.
I never claimed it wasnāt as extendable as other products. That would be an idiotic claim for me to make as Blender is open source. I claim it is a lot more hassle then in comparison with other products.
And as a developer I disagree. Having a plugin based interface doesnāt have a lot to do with working around closed source. Writing a plugin is a lot less work then cloning a complete branch and keep up with the code base. Yes plugins can also become incompatible with a certain version, but in all my live that I have written plugins it doesnāt happen a lot.
There are numerous open source applications that have a plugin structure or are extendable by c(++) plugins. Writing a modifier in another application (open or closed source) is just a matter of writing your code and āplugginā it in the main app.
Look at Wings3D for example and the CSG boolean plugin. You can plug it into you current wings3D version, easy as pie even for non technies. No need to keep different branches on your machine.
Off-topic:
I actually thought I had to pay for an upgrade to ZBrush 4.0. I seriously believed Iād have to fork out ~$600 US to get the latest version (and donāt have that money lying around). No, I donāt recall where I got that impression, but I am now a much happier man.
Looking on their website, I am guessing the fact I changed my email address a couple of times since my initial purchase hasnāt helped me :o
On-Topic (Plugins):
I have to agree with SilenceBe here. There is a big difference between branching a full application and being able to develop plugins such as those one can get/develop for Maya, 3DS, etc.
Whilst Python is pretty expressive, the Blender API has been pretty unstable (check out the back & forth in the development mailing lists everytime Campbell touches something without warning - now imagine the issues for those not subscribing and reading that mailing list). Besides that, there are some things that a scripting language like Python is just not performant enough to handle efficiently.
Take for example a recent feature I wanted to have, Lua Syntax highlighting. I have to hack Blender C & Python code for that, meaning a branch, and (after a short thread about it on the mailing list) I know that it will not be accepted into trunk. If I want to add syntax highlighting, even for just a couple of simple languages (e.g. Lua & GLSL), the development consensus is that I have to replace the entire text window code. And if itās not a priority, that might not get time for merging by core devs until after bitrot sets in.
(Off-topic Plugins) : For efficiency, use Python as the glue between your syntax highlighting lib and blender (although it does mean youāll need to distribute a binary for your lib together with your script). On the extensibility side of thinds, maybe some extension points are missing like adding modifers/syntax highlighting in Python.
On-topic: canāt wait for this branch merging party! Looks like it will result in an even greater and more useable Blender than ever!
Dani
Off-Topic (Plugins):
No can do, Dani. The syntax highlighting in Blender is purely native code with no hooks for inserting Python. Due to the way it is structure, it would not be a terrible burden to add in some fixed languages for syntax highlighting (Lua, GLSL, etc) but making the syntax flexible (through Python or scintilla) requires gutting the existing method and pretty much writing the text window from scratch. It was all discussed in the mailing list when I proposed the small changes.
As I said there, I donāt have the time nor desire to be completely re-writing features. Small patches I can do, but Iām busy enough without swapping family time for Blender text window reimplementation :o
On-Topic (Plugins):
I too am looking forward to the merge but more for looking forward than the immediate gains. My understanding from the meeting review in the dev mailing list is that we will (finally) be getting BMesh in there soonā¦ but with the deves writing up a list of things we can do without for the initial release.
In other words, if/when BMesh gets merged in (I am not sure from the meeting notes at what point that will be) - modelling will be taking a step back (again). At least this time though, it will be with the possibility of others patching in fixes so that bevel and so on gets added back in.
Of course, itās going to mean some major changes to the blend file loader in GameKit, but I think the trade-off will be worth it 
It is not superior to UnlimietdClay, is the same family of algorithms, in fact adding that possibility was in the todo list long ago as it was suggested for an artist, I just wanted to finish first the dynamic subdivision part, for UnlimitedClay is fundamental on relying on the edit mesh tools of Blender, in order to not start from scratch creating a whole set of new surface tools with new structures for subdivision, splitting, collapsing, flipping, etc like was needed for 3DCoat with LiveClay because it doesnāt have those tools to begin with.
Is true that creating a custom data structure can speed things a lot (and something similar seems to be what Nicholas has done) but it only solves the first half of the equation, thereās still huge performance issues with the sculpting due to the way it is handled trough a PBVH tree acceleration data structure, anyway, Iām sure a blenderhead like Nicholas can lead this project to a safe end.
Since I started UnlimitedClay I got tired to ask for an experienced blender core dev in that project to speed up progress, like I got the very important help of Matt Ebb for volumetrics and Jahka and Stephen for fluid particles, I do got a huge support from artist community for UnlimitedClay but dev suppot was mostly in words, I know weāre all busy guysā¦
The Freestyle approach has serious performance issues, as should be and the author says that explicitly, is limited to low detailed models since that particular āhole and mergeā feature is very processor hungry, and is a feature that can be added on top of āanyā subdivision sculpting approach, but Iām sure very fast implementations can be made and will be made 
So comparing perfromance you have this scale:
Static sculpting > Dynamic subd sculpting > Dynamic Topology sculpting
High res low-mid-high res low-mid res
Cheers
Just give them your name and if you still remember the old e-mail address theyt should be able to find it for you. They cover all that in their FAQ.
On topic,@farsthary, congratulations on your work with 3dcoat, it is looking really good. Anyway farsthary, Bmesh is gathering steam again by the looks of things, if things get merged and stabalized will we see Unlimited clay updated once done? and will these two features be compatible with each other for sculpting sake?
Last build of 3dc, farstharyās Live Clay works great, especially the decimator tool. Really smooth.
Canāt build anything serious though, the luck of great sculpting tools is killing me. Sculptris tools! Zb tools! Only this matters in the end. This goes for blender sculpting tools as well. Just a moment. Who cares about all these fireworks? Humble solutions, close to artists needs are what we need. Sculptris is a remarkable app just because of this. A great UI BTW