Blender would gain +3 Str, +3 Dex, +2 Def, and +1 MagDef if all of Nicks projects merged into trunk. Yes, it would be that awesome.
Funny how BMesh keeps doing that.The big problem to solve is performance, which halted Farstahy who's now waiting for bmesh integration before working further...
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...
Last edited by Michael W; 11-Aug-11 at 02:08.
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.
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.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 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).
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.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...
Last edited by BTolputt; 11-Aug-11 at 18:36.
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.
This would certainly rock.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!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....
Perhaps the blame for "not finishing" stuff should be put on the management of Blender development? Again, not a discussion for this thread 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!).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!
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 continuation... sorry guys...
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.
Though things can change at anytime. Taken from their forum.
So better get version 4 registered before things change... possibly[COLOR=white]ZBrush 4[/COLOR][COLOR=darkorange]R2 [/COLOR]will be released for both Win & Mac on 9/20/11! ([COLOR=Silver]September [/COLOR][COLOR=silver][COLOR=Silver]20th, 2011[/COLOR][/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.
I lost count how many branches are sitting in my Blender folder.
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.
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
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!
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
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
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?