The migration to the new developer platform is now complete, and preparations for Blender 2.70 have begun!
Ton Roosendaal writes:
Hi all,
Here are the notes from today's meeting in irc.freenode.net #blendercoders.
1) Migration to git and Phabricator
- Blender entered a new era of software development! What started with manual backups (1994), moved to cvs (2000), svn (2007) and now to git (2013). It's almost the 7 year itch :)
- Our online projects system also migrated, with GForge in 2003, to FusionForge in 2010, and now Phabricator. The Phabricator site has a lot better tools for organizing code work with large teams - including reviewing and managing feedback, research or patches. You can access it at developer.blender.org.
- Special thanks to the awesome work on this migration by Brecht van Lommel, Campbell Barton, Sergey Sharybin, Dan McGrath and Julien Rivaud.
- Remaining tasks are outlined here.
- Brecht will write a code.blender.org blog article about the new development environment, which will get link on blender.org frontpage as well.
2) 2.70 targets and scheduling
- It's BCon1 still - means we're gathering ideas for the upcoming release.
- Planning proposal: 2nd week of december move to BCon2, mid january BCon3, and release end of february. See the Blender 2.7x Release Cycle document.
- Lukas Toenne: posted a patch for EWA sampling in Compositor on the bf-compositor list, needs some review but this at least would partially fix the sampling issues we have there.
- Reminder for everyone, 2.70 is allowed to break forward compatibility.
- Brecht is working on a UI project and team announcement, will be posted in few days.
- Meeting discussed work we could do on keymaps and how to manage defaults or presets. Jonathan Williamson will contact people who might be interested in managing the Maya and Max "defaults". Brecht suggested to completely remove hardcoded C keymap definitions. This will be investigated further.
- Meeting ended discussing a lot of interesting other code projects, like for painting tools (GSoC), Beveling options, modeling roadmaps, Cycles, etc. Ton suggested to try to work this out better in the coming weeks and make it a proposed target for 2.70 in wiki.
Thanks,
-Ton-
44 Comments
I'll self-indulge to quote myself:
"hope this gets attention
[OpenVDB based particle Mesher by MohamedSakr]:
http://blenderartists.org/forum/showthread.php?284678-MSMesher
I deny or look for other software for few projects every year (that's a lot) because there is no particle fluid mesher."
Great news! Can't remember when news about Blender were bad. Thanks for that!
Totally agree on this! I have been waiting sooo long.
I think this is a great movement and could start a new branch. It can't be an addon because any serious simulation with meshing will take years to complete if it's in Python.
For editing meshes it would be really useful to add element to the selection (kind of like island in uv editing), so that we could have vertex,edge,polygon and element. Parts of the mesh that are separate objects could be easier to manipulate like that. Other than that, everything is super useful.
You can do it via "L" hotkey. Move mouse over the element and press "L", to select linked vertices/poligons.
It is not always accurate and it takes a lots of time.
Don't really understand - how can it be inaccurate? And pressing one button probably is faster than switching to another selection mode and back - no?
Smooth migration, thank you! :) My 1st bug report on the new engine and... it works great and very handy! Adding files by drag-n-drop was a nice surprise.
My new obsession is that such big (and CPU-hungry) features like fluid meshing, procedural modelling (like Sverchok) ought to be started as GPU-only (or hybrid) features. The current fastest system for this is CUDA. If it will be tied to OpenCL then will get overall compatibility but little (or even hardly noticeable) speed-up.
========== don't take these lines close to your heart ===========
For monopoly haters I'll say right now - I'm not against Ati, AMD or other alternative companies but I can't be a hypocrite, so I say "I need a well supported and a powerful GPU system. So NVidia now provides it. I don't care about any community's sentiments. I'm not a reach so I choose very carefully and prefer quality over price. Period." Please, don't argue to this, I don't want to start a "holywar", it's just "IMHO".
========== don't take these lines close to your heart ===========
As 2.7 is allowed to break backwards compatibility so why not to start something big and important that will not require to use old (CPU-age) technologies. It's not my Autumn caprice. I'm sure that the attention which Blender takes from mature companies will go further and let make a really "turn point software" that will change everything in CG industry (and not only). So making big and really competitive features with a hardware support up-to-date can bring more CG teams into Blender's "bowl".
My vision here:
pros: no need to code for CPU and for GPU, more users will be using these features as it will be fast and useful, Blender will be taken more seriously as it gives powerful and up-to-date features
cons: probably a lot of coders must be learning new principles to work in this section, users that has money just for cheap computers with weak (or just cheap) GPU cards will lose these features until they'll buy CUDA cards, CUDA limits usage of memory by it's own GPU RAM.
This third con is temporary as RAM is becoming faster and previous chips becomes cheaper so that allow to build card with larger memory for the same money.
P.S. I've tried to use OpenCL acceleration for Compositor. Seems that it's faster but I can't notice it. Maybe I'm dumb here :) So if you get other (excellent) results with a CUDA card, could you tell me (or show a thread about this) if I'm wrong. This is my point that OpenCL on Blender doesn't give a decent speed-up. Yeah, I can be wrong.
Just a quick note Kirill - Blender 2.70 will be allowed to break Forward, not backward compatibility.
This is counter-intuitive terminology, so correct me if I'm wrong here:
Backward Compatible - Later versions of application can open earlier versions files
Forward Compatible - Later versions can save files that can be opened in earlier versions.
In other words - blend files created in 2.70 may not function correctly in earlier versions, but 2.70 should be expected to open (or perhaps import would be a better term in this context) files created in Blender versions <2.70
Oh, yes! )) I've meant that in my head but wrote "backward" )) That's just a little mess about these conceptions in my head ) Logically all I've wrote earlier is right (except this mistake) and refers to the possibility of breaking forward compatibility.
That's spot on. Backward compatibility is common for software, forward compatibility is a crazy Blender feature :)
In the future, NVidia CUDA will be like Microsoft Internet Explorer 6 today.
Yes , AMD should be supported by cycles.
I agree. It's crazy that Blender, historically a hardware independent program, does not support a large proportion of users' hardware for one of it's major features and processor intensive tasks. Only yesterday I was reading a review of the AMD R9 290X that showed it was massively cheaper, but faster, than an nVidia TITAN - for games, anyway. Now although this might not translate to OpenCL Cycles compute power, the price alone makes the card a very attractive choice for any high-spec PC. It seems odd that Cycles is so hard to implement on OpenCL that the master devs at Blender HQ can't make it work.
Dig the subject. It's not "unsupported", it just doesn't really work when things get complicated. There is a thread on AMD forums on this topic. AMD promised to fix this but still didn't.
Today i just ordered AMD R9 270x because of its budget friendly performance. Now only thing that will make my gambling more worthy is proper AMD support on blender and i guess that moment would be the happiest day for amd users..:-)
I have a very limited budget. But I'll be buying any fast NVidia cards in future anyway (already bought a good one about 2 years ago, that was just 100$ and I got a profit). At least until AMD will stop acting like everything is OK.
@Konstantins: Thanks for mentioning that AMD forum thread. I read it, and now see that it's all AMD's fault! I'm sure the Blender devs don't like the situation either, but at least AMD say they are making slow progress on the problem...
My whole point wasn't about that :) If you'll chase WHY it's not supported... you'll be surprised. Just try.
OK i read many forms and sites on this subject and I finally found that cuda support some fuction calls method while AMD OpenCL compiler makes a clone and stores a copy which makes it unstable (this what i read!!), but than Luxrender grabs my attention, kinda Genius ??
10 years ago my rock stars were ppl like kurt cobain, jim morrison etc etc etc.... now blender devs are just like those to me. ty for this incredible software
Yeah, well, let's just hope that none of the Blender developers end up like these rock star guys (I mean, alcohol, drugs, and early grave).
Apart from simply not wishing such fate to anyone, my (not inconsiderable) experience in software development tells me that any software that was developed with alcohol does not work without it afterwards, and that would be really bad for the community! :-)
Hey.. just a silly question:
What is git and what is it's advantages?
Thanks to Ton and to all the devs that make Blender a reality. You guys continue to make history!
If you have used version control before, then the power of Git is in how nicely it handles branching and merging. This is a great boon to collaborative development.
1* alembic
2* fluid mesher
3* GPU Fluid Solver: FLIP
How about some NURBS-love? We are way behind most other 3D software. Just the simple import of some popular spline-patch file formats would be super, even without any new modelling tools. This would make it much easier for many freelancers and companies to adopt Blender for industrial visualisation!
In 2.70 I would like to see:
- Shallow water system (like: http://www.youtube.com/watch?feature=endscreen&NR=1&v=FbZBR-FjRwY)
- Fluid mesher
- Function to enable particle collision easily (e.g. to easily fill up cups with particles etc.)
- System to compress particles inside a mesh (e.g. cloth inside a suitcase)
Thanks!
Hi,
A great improvement for 2.7 would be a python node for the compositor.
This would allow to relatively simply implemtent extrenal graphic style addons/filters using existing tools such as g'mic. http://gmic.sourceforge.net/
So the future compositor would be able to create various filtres (Sketch, Comic etc...) such as Gimp or PS.
Thanks!
Salutation,
Je n'ai qu'une question : Quel studio choisirait un logiciel qui n'a toujours pas de collision de cheveux ou de particule correct ?
Le moteur de rendu interne de blender suffirait déjà a beaucoup de studio de production ainsi que tout les outil deja en place.
Mais que faire d'un logiciel qui m’empêcherait de faire des acteur a cheveux long ou de ne pas pouvoir utiliser les particule en dynamique.
Merci
Boy, I'm sure looking forward to improved painting tools. There are a few things I'd love to see someday:
- bucket-fill tool (at last word, I think this was already in development, but I'm not sure of its status)
- gradient tool (same situation as bucket-fill tool)
- marquee selection tool to allow delimiting regions to paint more precisely (could be done via Grease Pencil, though a dedicated marquee tool might prove more precise)
- incremental snapping of texture masks (stencils)
- "stencil wrapping," a feature that allows you to wrap your texture masks (stencils) onto the models directly and paint on them*
- paint along curves (you could use Bézier curves/paths or Grease Pencil lines)
- masking supported in Texture Paint mode
- texture-mask-into-mask conversion
I'm hoping for a few sculpting tool improvements eventually as well:
- group vertices by masking
- sculpt layers with opacity control
- mask-by-layer option
- snap-to-curve sculpting (sculpt along Bézier/path curves or Grease Pencil lines)
- toggleable "cursor follows surface" option (think of the cursor in Sculptris or ZBrush, where it moves perpendicularly along the surface plane's normal)
- global deformation options such as Smooth/Inflate/Balloon/Twist/Polish/Relax/Taper/etc. that work on unmasked regions while leaving masked regions unaffected
- array brushes (create arrays of objects along a drawn Grease Pencil curve, and allows edits of those arrayed elements such as spacing, tapering and thickness)
And, while I'm confident that Blender's modeling tools will continue to improve, I hope some features are someday introduced rather sooner than later:
- persistent parametric modification (in other words, if I make a 16-ringed sphere, edit it a bit, but need an 8-ringed sphere instead, I can re-modify its basic parameters)
- vector displacement maps
- an equalized quadification option with the Remesh modifier (where you can remesh models with even, uniform quads rather with similar orientation)
Of course, this stuff takes time and priorities must be weighed, but I hope to see some of these features eventually, hopefully sometime during the course of 2014. We can do most of these functions in some other software elsewhere, but it'd just be really nice and efficient if we could do it all without leaving Blender. A guy can dream.
* I work with terrain models a lot and since displacement maps aren't supported in Blender (yet), I have to deal with all surface deformation manually. That means that painting inside 3D concave regions using a 2D-plane stencil sometimes proves tricky. Sometimes I just wish that I could pin the custom erosion stencil masks flat down onto the model's surface itself, to not have to deal with 2D-plane stenciling.
Currently, only ZBrush makes such a workflow possible, thanks to its advanced masking features. No one else out there among 3D-painting software, such as Mari or Mudbox, seem to exhibits such a simple but useful feature either.)
I'm hoping for a few sculpting tool improvements eventually as well:
- group vertices by masking
- vertex-group-based sculpting (already possible to some extent; would benefit from focused improvement)
- sculpt layers with opacity control
- curve-as-brush surface sculpting (use a draggable curve snapped onto the surface as a manipulator of the surface, to achieve raised or engraved effects, make "snaking"-like raked patterns across the surface, making coiled designs, or drag alphas brushes around dynamically)
- mask-by-layer option
- snap-to-curve sculpting (sculpt along Bézier/path curves or Grease Pencil lines)
- toggleable "cursor follows surface" option (think of the cursor in Sculptris or ZBrush, where it moves perpendicularly along the surface plane's normal)
- global deformation options (such as Smooth/Inflate/Balloon/Twist/Polish/Relax/Taper/etc. that work on unmasked regions while leaving masked regions unaffected)
- array brushes (create arrays of objects along a drawn Grease Pencil curve, and allows edits of those arrayed elements such as spacing, tapering and thickness)
I guess that Dyn-Retopo will wait until DynTopo will be x3 - x5 times faster... Remesh is slow itself (in terms of sculpting speeds so to say)
+1 for kitbashing - but it's not very useful without a fast Boolean algorithm (yep, Carve is faster than the old one but isn't fast enough)... or some fast remeshing algorithm. These are "brothers" I guess... or father and son :)
For the start we need just some BASIC tools for more comfortable sculpting:
- set switch on/off for a sculpting mask
- save a mask (!) - can be saved to some cache-like files. I need some different masks and wish to use one or another. It's a common situation.
I guess it's not hard to implement these things.
OF COURSE: bug annihilation is superior! Once Blender is bugged too much it becomes horrible to work in it even with all new cool features. :)
I think there's a rather simple way to improve at least the Remesh functionality. In fact, I think a uniform-quadification option would actually perform much faster than the Remesh's current method, since it's a lightweight method.
The secret is to form an auto-retopology functionality. I think we can design an auto-retopo functionality in Blender based existing tools. So far, I've been looking at this way:
1. Create a new "Skeletalize Modifier."
This modifier would do the inverse of the Skin Modifier. It would be needed so that we can build a "guide skeleton" (the same kind of vertex-based control frame the Skin Modifier produces) within our already-built mesh to guide along retopology (direction/orientation of edge flow).
Just like how the Skin Modifier determines the form by generating geometry around the control vertex-based frame as its general center, the Skeletalize Modifier would do the inverse in determining a control vertex-based frame from the general center of the sculpted geometry.
Since guide bones are just vertices, which are very lightweight, Blender can us as many guide bones as needed can be generated to best preserve the detailed forms of the mesh. If the model is symmetrical, the function can save time by only generating one side of the model with a guide skeleton and mirroring it afterwards.
2. Adapt the Contours Retopology tool for an auto-retopology tool.
Jonathan Williamson and Patrick Moore's Contours Retopo tool is a wonderful development, and I think we can see it used to produce a new auto-retopo tool as well. It'd use the guide skeleton as a general path to follow with retopologizing the sculpted model.
This part of the process only uses the guide skeleton for direction/orientation for the edge flow--the resolution of the new topology would depend on Contours determining the area and angle of the forms. The direction/orientation of the edge flow would be kept independent from the resolution of the generated topology, so that the resolution of both remain adjustable, if desired.
All protrusions and extrusions with the sculpted model would get their own extension of guide bones underneath, with a skeleton resolution in accordance to their detail level, so a delicate form such as a nose would see a finer series of guide bones around the nostrils and at the columella while a generalized form such as a torso would see much broader guide bones.
3. Present clean-up tools in a ready way.
Both before and after the auto-retopo process is executed, a menu could pop up to allow users some clean-up efforts to the sculpted mesh first before processing and the retopo mesh after processing, if needed.
This would allow everything from checking the mesh for holes and intersecting geometry (features drawn from "Clean up" and Mesh Analysis), adding resolution and smoothness to the retopo'd mesh (Subdivision and Smooth modifiers), and guiding edge flow via Grease Pencil for plotting or correcting edge flows.
Basically, this final step would include just providing a handy way to ensure "air-tightness" with the two meshes before finalizing the retopo'd mesh. These aren't really new features as much as they'd just be a convenient way to speed up the mesh clean-up process.
Just an overview
This is just one general look at the method we could try. I think this sort of route towards auto-retopology (and consequently, uniform-quadification remesh, rapid Boolean operations, and guided auto-retopology) might be worth checking out, because it uses a lightweight manner to control the process, and there's no storing all of the vertex information of the original sculpted mesh.
It's memory-light, fast, easier to develop (since we're merely repurposing existing tools here), and might would even more accurate results than most other (pixol-based) auto-retopology methods out there, because both the resolution of the control skeleton and the edge flow are independently adjustable and the calculations are relying on direction/orientation rather than mathematically-intensive surface curvature.
What's more, I think once we'd see an auto-retopology tool in Blender, things like a "DynRetopo" and better Boolean operations can be implemented rather immediately. Guided auto-retopology also become immediately possible, which would make a nice time-saving mix between manual retopology and automatic retopology. Auto-retopo functionality would open the door to many possible future features.
Blender, "the world's most advanced 3D package for sculpting and 3D texturing"
If Blender had these tools, it'd immediately become a program with fastest and most convenient 3D sculpting/retopo functionality anywhere. ZBrush is a beautiful tool, but sometimes, people just want straightforward, no-fuss sculpting and retopology. I think with some of these ideas I've listed overall, Blender would become the program to turn to for solid sculpt-and-retopo workflows, along with (hopefully) advanced 3D texturing tools.
I'm not a pessimist... But although Skeletalize idea sounds cool and almost proven I don't think it will be so easy to implement. I'm not a coder but all I remember (seeing my colleagues working hardly) that almost any cool idea meets very "cool blocks"... corner cases (tell me if I call it wrong).
BTW Contours isn't complete as we know. If it could be so easy then I think we could see Poly strips already.
It will be very interesting to know what Devs and experienced coders can tell about these ideas!
A Skeletalize Modifier wouldn't be too difficult to do in terms of development--it's essentially just going the other way that the Skin Modifier already takes: set a vertex in the center inside of the 3D mesh region and place a vertex wherever extruded regions are at. Programmatically, it shouldn't be too difficult to implement.
You're merely just trying to find the center position in of various places within a 3D mesh and placing a vertex there, until you end up with a series of vertex to describe a center line running through the mesh. And wherever you have extrusions in conjunction to the longest center line (such as fingers and arms) and loops (like nostrils and eyes), you'd start a new branch of center lines and ring loops as well, until you've created a lightweight vertex-based skeleton.
In fact, you'd only need to be as precise as finding the center inside of a 3D region, because you're only trying to define a mere path for guiding the direction of the auto-retopo, whereas with the Skin Modifier, you're trying to guide the generated mesh's direction and width (with Ctrl+A to expand the vertex points while using the Skin Modifier).
All surface-snapping of retopo'd geometry from is handled by guiding new geometry shrinkwrapped following along the path, rather than merely the surface of the model. Since the Skeletalize Modifier would essentially just be a more precise way to shrinkwrap new retopological geometry, there's no need to have anything more complicated than having a simple paths of vertices running along as a body of centerlines of the 3D mesh..Theoretically, a Skeletalize Modifier should be even simpler than the Skin Modifier to develop.
The biggest issue with my idea in general is that this sort of idea would just take focused development to do, as in from a team working on it simultaneously, rather than just the current "one-man-assigned-to-one-development" route we typically see. It'll have to be a team-effort to have the Skeletalize Modifier developed while seeing adaptation with Contours to develop auto-retopological features.
I'm aware that Contours is still in development. The only reason why Contours isn't being developed so easily is because they're only just two people developing it, and only one of them being the actual programmer. It's also being funded through sales, which means that it's part-time development, which in itself can only go so far at a time. Though, since I'm talking about adapting Contours with new functionality anyways, it's current incompleteness doesn't matter.
This why I recommend that an idea like this would need to see some group-focused adaptation of all the components necessary to make an idea like this one (or something similar to this one) a reality. Blender is fortunate enough to have an actual team of developers, and Blender has a unique position in that it's free to develop however they chose.
While I do understand the nature of the "one-man-per-different-development" model they often employ, some ideas just come down to the whole team (or enough of the team) coming together to focus on one major project--a project that's going to lead the way or more and easier "one-man-developments" and multi-man developments in the future.
And, while I'm confident that Blender's modeling tools will continue to improve, I hope some features are someday introduced rather sooner than later:
- persistent parametric modification (in other words, if I make a 16-ringed sphere, edit it a bit, but need an 8-ringed sphere instead, I can re-modify its basic parameters)
- vector displacement maps
- an equalized quadification option with the Remesh modifier (where you can remesh models with even, uniform quads rather with similar orientation)
- Improved NURBS modeling (such as Boolean operations for NURBS)
Of course, this stuff takes time and priorities must be weighed, but I hope to see some of these features eventually, hopefully sometime during the course of 2014. We can do most of these functions in some other software elsewhere, but it'd just be really nice and efficient if we could do it all without leaving Blender.
+1 to
paint/sculpt along curves - I've mentioned about this in some BA thread. It's very necessary especially for sculpting. I see it just like that:
you make a curve, use 3dView position to paint anywhere so strokes are projected and flexibly snapped to that curve. "Flexibly" means that in a cases if you have more curves (OK, these are future features for non-existing feature :) ) then a stroke will be following the closest one. So called "tolerance".
This is my "most starving about" feature in this section.
I hope level of detail makes it this time!
One thing I miss from 3D Studio Max is the simple and versatile align tool. Haven't found anything similar in Blender and I think it would be great if 2.70 had such a tool.
How about completing some of the GSoC projects. They seemed important enough when assigned to students but when they aren't complete, they get transferred to the bit bucket. Been waiting forever for precision modelling tools.
Good question! I'll ask around and see what's going on with these projects.
right