Yep, it was issue with space transformation here… I was thinking about additional check to prevent baking to higher level. Or this would not good solution?
I see no interest to bake only a low level of sculpted data.
But it does not work with lower level, too.
It is only the level used in viewport that can be baked.
When sculpting, we already decrease multires preview level to 0 to free memory.
When we quit sculpt mode to object mode, displayed level is 0.
So, with current behavior, we have to be carefull in what mode we are, what level is displayed in viewport and “Bake to level” setting in Bake panel is a useless waste of time.
From my POV, optimal behavior is to bake the higher level of sculpted data without taking account of what level is displayed.
If it is not possible, for example, to have preview level to 0 or 1 and bake level to 7; synchronize displayed level with “bake to level” setting in order to change displayed level at each modifying of “bake to level” setting.
Or just remove it and add a message in bake panel to explain that displayed level is the baked one.
A decent set of presets makes a huge difference… just look at “MyPaint”.
Brush datablocks are a bit clunky to share and update in new blends… just load an old file and try and append! it takes far to much additional setup just to get the default brushes from a startup blend appended!
The main issues I have with the current UI are the overflow of settings… most of which could be ignored with decent presets!
I think that a structural change is needed to really clean up the paint and sculpt UI…
that is we need to drop using “startup.blend” for default brushes and brush textures. instead lets have more preset folders…
With the current py api it may well be possible to store presets as py files… I discussed this with Ton ages ago with teh idea of doing a material library script… he prefers c and binary which pretty much put it beyond my skills… but having some libraries that could easily be appended to files without additional clunk perhaps managed independantly of the file would be a great thing!
One element of sculpt that has been bothering me lately is the move brush. Since 2.49 the default move brush has become very hard to control, it may just be a difference in fall off but I can’t quite tell.
The solution i found to this was to use a blend texture set to spherical, add a ramp from transparent to varying degrees of grey depending on how much influence you want the grab brush to have. Works a treat with loads of control.
Also change the interpolation of the ramp for different influences.
Hi all, we really need better sculpt curves - handlebar can you save out the texture ramps that you use? Same for others any curve that you’ve created that works really well for a brush, or a preset curve that works really well - please let us know a) what curve (sample blend file if it isn’t a preset) b) what brush algorithm it works well with
Totally agree about making brush presets as a separate file. This would make upgrading to new versions and sharing brushes amoung the community much easier. Or at least I wouldn’t have to rebuild the clay tubes brush with every new version of Blender.
Agreed. It’s just way too much hassle to share brushes at the moment. Also is there any word on if there will be any focus on a faster/more efficient way to switch between brushes? (Radial menu, better shortcuts, etc)
Hi everyone, this is Antonis Riakiotakis (or Psy-Fi). I will be posting all major features developed in this thread and I welcome any feedback. You can find these features at the onion branch, which is shared by Jason Wilkins and me (https://svn.blender.org/svnroot/bf-blender/branches/soc-2011-onion/). So, laterz!
Hi all, here is something that would be useful that users can do, is create keyboard presets for mudbox, zbrush, sculptris, and 3d coat
http://www.pixologic.com/docs/index.php/ZBrush_4_Shortcuts
http://members.casema.nl/jw.v.dronkelaar/sculptris_cheat_sheet.pdf
http://www.3d-coat.com/wiki/index.php/10.1_All_Hot_Keys
To make it easier for users of those other programs to use blender.
First draft of hi-res textures is in! Feedback is welcome. From log:
GSOC - 2011
— first draft of high resolution texture support in 3D view. —
This commit is still early development proof-of-concept and has a lot of restrictions.
Known at the moment are the following(but, of course the number of issues to increase)
- Tiled textures are not supported yet and may break
High res textures need float images! Normal 8-bit images do not support high res textures(what would be the point anyway? :))
http://www.pasteall.org/pic/12761 for a sample
n’Joy 
Just built again, really responsive even on 4k 32bit textures! and now the GL view is showing better too!
EG: when using Sparkys bumpmapping with a 32bit texture all those “terraced” artefacts are gone (especially with procedural brushes… now I need to dump all my 8bit brushes and make float ones!
(and watch out for using too much memory and making my system crawl ) (note to self : 20millon faces may be fine in sculpt mode… but object mode not so much!
this is my idea
I think the possibility of strech the tool shelf infinitely is cool, but would be much more cool if automatically (at a reasonable size) the TS will split automatically
Ok… here are a few suggestions/critiques that would make the whole painting a lot smoother I think!
-
Painting gets really laggy when I use a brush with a very small size. I think this is caused by the translation between brushsize to pixels I think. But I think that the developers are aware of this problem.
-
I would love to have the colorpicker behave a bit differently! At the moment the colorpicker gets the physical color that is actually visible in the viewport. In most cases it is unusable this way(It only works in Multitexture Mode not in GLSL). It would be great if it gets the color of the textur instead. This way you don’t need to have a texture window open where to pick the color!
Here are some thoughts concerning bumpmap painting!
As it is suggested by Jason Wilkons that he wants to unify the paint and sculpt mode in blender I think it would be great to add a few functions to painting!
-
When I create a layer with a bumpmap factor it would be great to switch the color from black to white via CTRL. This would give the same effeckt as in sculpting that you can add or substract the bumplevel!
-
Also it would be great when you press SHIFT while painting that the brush changes to the smoothbrush! This would be also a similar behavior as in sculpting!
-
As above already mentioned a new colorpicker will do a great job too in this situation too! When pick a “bumplevel” via a color directly from your model. This way you have a very precise control of the bumplevels. That would be good for technical bumpmap painting!
I hope this helps you a bit! I am looking forward to this soc! I wish you good luck!
Hi and thanks for the suggestions!
First I would to ask for testers regarding some color correction issues.
Currently (r36953, onion branch) we have a limited working color correction for float textures.
I would like testers to check and evaluate whether color painting without texture brushes (e.g simple color brushes) on float textures gives better results than 8-bit textures. Please use projection painting, image editor is currently slow with float textures(working on that)
*ndee
I can’t see the lag issue you are describing. Are you painting in the UV editor or in texture paint mode?
I also like the ideas about shift-ctrl painting though you’ll have to wait until Jason’s work gets merged into onion. The color picker tool looks a bit involved so I don’t know if I can handle it with my time resources.
*Michael W.
There will be an option to use low res textures if one wishes so.
will you add stencil painting or will they use code from the ptex work?
Nickolas Bishop’s work will be merged with onion. I haven’t seen his code yet, so I don’t know for sure but I’ve heard the feature is there in some form.
Here’s a question. Is there a way to take higher subdivision level sculpting and copy it from one mesh to another of different topology?
So for example, I have this sculpt that was made from a subdivided cube:
It has tiny wrinkles and textural information on the surface that I want to get back onto the retopologized geometry. I know I could bake a normal map, but is there any way to, say, get the hires information copied to a multires modifier added to my new retopologized version?
So if the answer is no, here’s where I think a zproject brush could come in handy. The way I could see it working is you have your original scuplted mesh with bad topology visible, select the new geometry, add a multires modifier, subdivide a few times. Then choose the “zproject” brush and paint, and it effectively shrinkwraps the geometry to whatever is underneath the brush stroke.
If we had something like this, I could pretty much leave zbrush entirely.
you could bake displacement maps than apply the displacement map to the new head.
Sure, absolutely, but that’s the limitation. You can’t keep sculpting on the new head once you’ve gone to displacements. Unless you want to manage a new multires modifier and those displacements. Besides, there would be a lot of other great uses for a brush that projects the geometry down in z-depth to whatever is beneath the geometry you’re currently sculpting on.