Although I’ve been quiet on the website, I’ve continued work on dynamic topology sculpt mode. All of this work has been of the non-exciting variety; there are no new features, just cleaner and more robust code. In particular it took a while to figure out how to get everything in the undo system to fit together, but it’s working pretty well now in terms of stability. Undo/redo of masking and hiding works now too. The smooth shading toggle is more robust, the info header stats show new vertices and faces created during sculpting, and the mesh wireframe toggle is fixed.
With the code now much closer to being merge ready, I’d like to get some user testing to shake out bugs and find things I’ve overlooked. I’m particularly interested in ways to crash dynamic topology, problems with undo/redo, and problems with saving or loading. If you find a way to reliably reproduce an issue please describe it in the comments. (I’ve been keeping a list of test cases for undo/redo, that’s the sort of steps-to-reproduce I need.) Please check that you have an up-to-date build before reporting issues. The code is still in the dyntopo-slim branch here: https://github.com/nicholasbishop/blender/tree/dyntopo-slim
Another thing I could use a hand with is getting an icon for the “Enable Dynamic” button. Right now it’s reusing the remesh modifier’s icon as a placeholder.
There is still a significant amount of work left to do before dynamic topology can be merged into trunk, but we’re getting closer now. Thanks to everyone who has helped the project along.
Update: just pushed (4:03UTC, Dec 4) a fix for a crash when collapsing edges.
As always, thank you for your hard work. :-)
This is probably not the kind of bug you are looking for, but trying to sculpt with the ‘persistent’ option for the layer brush crashes Blender.
That’s exactly the sort of bug I’m interested in :) Added to the TODO list.
uploaded windows builds to graphicall.org
here are the links
http://www.graphicall.org/1001
http://www.graphicall.org/1002
Thanks for continuing to do builds. If you feel like doing some more, I’ve pushed a small fix for a bug in collapse-edges.
thanks!
I’ve updated
does dyntopo now work on uv textured models in texture viewport mode?
No, dyntopo only does solid shading for now.
Also, it still often crashes just going out of sculpt mode and/or dyntopo mode. Unfortunately it’s impossible to create a file that crashes consistently because dyntopo is always turned off after the file is reloaded.
Are there any repeatable steps you can find that reproduce a crash? Or can you provide a backtrack? Without one of these there’s nothing I can target.
The only consistent part I noticed about those crashes is that they occur after activating and using dyntopo on models with very long, narrow faces, like hard surface subsurf results. I’m no programmer, so I don’t have VC set up to build and use debug builds for the backtrace. I’ll try to get VC express or install linux over the next few days.
Sorry for begging for a feature instead of reporting a bug, but there is one thing that would improve dyntopo significantly: Enabling dynamic topology for the grab brush. This would allow to flesh out the rough structure way better. It works like that in sculptris and its very helpful.
It’s already there. Use the Snake Hook brush instead of Grab to have it dynamically tessellate the surface as you pull.
Another thing I’ve found that make the Grab/Snake-Hook brushes feel more Sculptris-like, is to add ~0.25 normal weight… dont’ ask me why, but they’re much easier/smoother to use after that.
Use snake hook. I’ve had to explain this so many times I’m starting to think it may actually be a good idea to enable it, or rename snake hook to ‘grab – dynamic’. Users don’t usually think to try them both.
Thanks for the tipp, MadMinstrel! And yes, I think “grab – dynamic” would be a bit more intuitive. The icon at least to me gave the wrong idea. One just expects different behaviour especially regarding default falloff of the tool.
This is something I will try to clarify in the user documentation — notes on how various brush types interact with dyntopo.
For me, Dyntopo seems to be running crash-free. However, Isolated verts/edges are still created (though they’re easy to get rid of). This might have something to do with Collapse-Short-Edges, which I enable sometimes to clean up the topology or when I’m extending large areas (and it’s an awesome feature of Dyntopo!)
I’ll try and do a bunch of Undo/Redo stuff and see if I can get it to crash. BTW, I’m runnig Arch Linux 64 and building against Python 3.3
compiled with mingw64 & cmake(scons fails at the end linking the blender.exe not sure why)
anyhow.. with the mingw64&cmake, it works fine..
I don’t see much difference now and what you had several weeks ago..
its “stable” works as expected. the scons not compileing is not exclusive to your build, trunk will not compile on windows mingw64+scons either
(although it used to, not sure what happened)
Hello Mr. Bishop,
The following is a feature request, not a bug report. If there is a more appropriate place to post it, let me know, and in the future, I’ll do it.
I am very excited about your work with Blender’s dynamic topology sculpting and am extremely passionate about digital sculpting. It is for these reasons that I feel compelled to inform you that, in my opinion, a particular aspect of it is developing in the wrong direction. Namely, the current tessellation density appears to be governed by the 3D view distance.
The foremost goal in developing dynamic topology sculpting should be that the user can sculpt without concern for the underlying mesh structure. The Dyntopo-Slim branch adjusts tessellation density according to view distance, which conflicts with this goal.
Consider the following scenario:
The user has a dynamic topology enabled plane facing the camera. With a large radius brush, he draws a stroke across the surface. The stroke appears a bit blocky so he hits undo, lowers the “Detail Size” slider, and repeats the stroke. This time it looks satisfactory. Any additional strokes across the surface will maintain this visual fidelity and have approximately the same surface density of triangles. Now the user reduces the brush size while maintaining the view distance. Upon making a stroke, he notices that it appears blocky. The “Detail Size” value is the same. The view distance is the same. Therefore, the surface density has not changed. Using a smaller brush means that fewer triangles are available to accommodate the form of the stroke, thus the blocky appearance. Currently, he has two ways to rectify this issue before continuing with the sculpting task.
The first option is to decrease the “Detail Size” once again. It is obvious how this is contrary to clay-like sculpting and makes the user aware of the underlying mesh structure. Also, it is understood that the user would have to do this anytime he decides to sculpt in an area that doesn’t provide an appropriate level of detail.
The second option is to dolly the view in, decreasing the view distance value. This has the effect of increasing the tessellation density in relation to the mesh area. The stroke is no longer blocky and any additional strokes of the same or greater brush radius at the same view distance appear good. However, if the user then reduces the brush radius or zooms out, he will likely have to deal with the issue of blocky strokes again. Observing this behavior, one can identify three problems that result from making tessellation view distance dependent:
(1) It restricts how freely the user can navigate in 3D space.
(2) It forces the user to be mindful of view distance, thus distracting from the sculpting task.
(3) The user will make blocky strokes, thus detraction from a clay-like experience.
(a) The only ways to avoid blocky strokes are by the improbability of always correctly guessing the needed view distance each time after decreasing the brush size or by not changing the brush size and dollying in and out to adjust the brush size in relation to the mesh object. The latter is applicable to (1).
I believe that the proper way to implement clay-like sculpting is to associate the tessellation density with the brush, not the view distance. I find it difficult to explain, but let’s just imagine that a brush, given a certain “Detail Size” value, is capable of tessellating the mesh into 100 triangles under the area of influence of the brush. A large radius brush creates 100 large triangles and a small radius brush creates 100 small triangles. This behavior affects how each dab of a stroke appears. A dab that looks smooth with a large brush radius would appear every bit as smooth, only proportionally smaller, with a small brush radius. The actual mesh density in terms of triangles per mesh surface area will vary depending on the brush size, as described previously, and the distance between the view plane and the sculpted area of the model–a brush of fixed size along the view plane affects more of the mesh surface area as the view depth increases and the object foreshortens (perspective mode only).
This approach gives the user a more clay-like sculpting experience where he can sculpt without concern for the underlying mesh structure. Here is an expected scenario:
The user has a dynamic topology enable mesh. With a large radius brush, he draws a stroke across the surface. The stroke appears a bit blocky so he hits undo, lowers the “Detail Size” slider, and repeats the stroke. This time it looks satisfactory. Any additional strokes across the surface will maintain this visual fidelity no matter the view distance or brush radius the user chooses. In comparing this scenario to the respective one for a view distance dependent approach, it is evident that the user’s sculpting experience is more natural and sculpting focused using a brush dependent approach. He needs only initially to decide upon a level of detail necessary to achieve a satisfactory looking stroke. Then, he can focus entirely on the sculpting task.
As I mentioned, I find this difficult to explain clearly. I am trying to describe the approach that Sculptris and Mesh Mixer use, according to my observations. So, if there is anything that I did not explain in absolute clarity, I suggest that you play around with one of those two applications to understand visually what I am trying to communicate in writing.
I am grateful for your contributions to Blender and entirely understand that this is effectively charity work. You do this on a voluntary basis. You have every right to decide how to implement dynamic topology sculpting. If you disagree with the approach that I detail as being “better”, I stand by your decision and respect it. I merely am making a suggestion that, in my personal opinion, will improve the experience of the Blender users.
With ALL of that said, your bug fixing work obviously takes precedence. Please, consider this as a suggestion for future development, i.e., after integration into trunk.
Best regards,
Iso
I respectfully disagree with your opinions here. While sculpting, I rarely, if ever, need to adjust sliders before doing single strokes, or anything like that. I may adjust the density slider if I feel I need a bit more resolution to my strokes in general, but that’s about it.
When sculpting, you’re constantly adjust the view angle to get the correct angle for your strokes, so adjusting the camera distance fits in naturally. It’s very natural, really. You need to draw small details? Zoom in and draw them, you’ll have the resolution to do so. Need to move/flatten large areas? Zoom out. It’s this basic dynamic that makes Dynamic sculpting so much better than Multi-res sculpting.
Wow, that’s a very long post. As for me I actually like the view-based tesselation as long as I’m doing non-precise, creative freeform sculpting. It was highly annoying however when I tried to use dyntopo to add some detail to hard surface models. I put a feature request in the issue tracker for this so I won’t repeat it here. What I envisioned however was not based on brushes, but simply max edge length in blender units, which is coincidentally exactly how it used to work in the very first builds.
I think it’s reasonable to consider having alternative methods of setting detail size. As you noted, bug fixing and getting dyntopo into trunk take precedence, but will think more about this after that’s done.
Nope, it’s fine as it is because its easier to stay on the current level of detail. Otherwise you would very quickly hit the amount of detail which will slow the computer to the level it is no longer workable.
As Philip said, it more natural to just zoom in and put some details.
However I too feel that the detail size needs to be able to adjust like brush size for instance (for instance drawing couple of triagles in the brush circle for the preview).
And while I’m at it, one last rant:
HWO THE FU*K PUT THE V KEY AS THE VERTEX PAINT SHORCUT. I cant find where to get rid of it and I constantly keep hitting in on the keyboard instead of clay brush. Its driving me mad.
I’ve looked trough the outliner but theres no vertex paint mode anywhere. This needs to be removed man.
6 of 1, half a dozen of the other.
i guess, i would be nice to have to the option to do either.
however, i don’t see i huge “need” for it right away
if its something that wold be troublesome to do.
something like the “brush radius” lock (which blender has)
Allows you to either have the brush size stay the same size as you zoom,
or the brush size changes with the zoom levels.
“When locked brush stays same size relative to object, when unlocked brush size is given in pixels”
Why my comments aren’t published?
I don’t see any other comments from you in the system (nothing flagged as spam), must just be some mysterious glitch.
I wrote two time a comment trying to report some bugs and how to replicate them. You can read my comment on BA:
hxxp://blenderartists.org/forum/showthread.php?257749-The-Dynamic-Topology-Branch-is-here!&p=2253281&highlight=#post2253281
Did you improve the collapse short edges code since 2th December? The second bug doesn’t happen anymore with today build uploaded by vitos1k, and the collapsing of stretched faces is faster.
I’m having a problem downloading the build… can you upload the software to other place… when I download it from graphicall it ALWAYS cuts the download… like a server timed out problem…
I’ve already used DAP, Internet Download Manager and even wget… but it is still having the same problem downloading it… please help… :))
I managed to crash Blender. I have about 80k tris on a model in sculpt mode. If I disable dynatopo in sculpt mode and try to switch to object mode, Blender crashes. If I enable dyna before trying to go back to object mode, it works. Not sure if this is a bug or just my system.
Do you have a file that reproduces the crash that I can test with?
Yeah. I think you can grab the file from here: http://rapidshare.com/files/3396589778/test.Crash.blend
If you don’t enable dyna and try to go to object mode, it should crash. At least it does with me. If I enable dyna first, then select object mode, it won’t crash.
I’m trying to build it for the mac but I’m having troubles.
errors in my console: Auto-setting available MacOSX SDK -> MacOSX10.7.sdk
3D_CONNEXION_CLIENT_LIBRARY not found, disabling WITH_BF_3DMOUSE
JackOSX install not found, disabling WITH_BF_JACK
and: Missing: Python.h and/or pyconfig.h in”#../lib/darwin-9.x.universal/python/include/python3.3m”,
Set ‘BF_PYTHON_INC’ to point to valid python include path(s).
Containing Python.h and pyconfig.h for python version “3.3”
pleas tell me what is wrong or just post the right steps to do it right because I’m not sure if I am doing it right.
-Bert
It sounds like you don’t have the dev headers for Python 3.3 installed. I’m not familiar enough with OSX to provide much help, but perhaps this helps: http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Mac
Try this:
$ cd path/to/blender/sourcecode
$ make BUILD_CMAKE_ARGS=”-D PYTHON_VERSION=3.3 -D PYTHON_LIBRARY=/path/to/python/shared/library -D PYTHON_INCLUDE_DIR=/path/to/python/include/dir”
On Linux (Arch), the Python Library and Include Dir are:
/usr/lib/libpython3.3m.so
/usr/include/python3.3m
IDK what they are on Mac, so try searching your file-system for Python and see if you can find the lib/include directories.
I’ve got the source from github. Just built it in order to find some reproducible bug (since previos version never crashed). After hours of building… there’s no dyntopo option in sculpt mode!!!
Under build config I don’t see how I might have disabled dyntopo, so prolly I got the wrong source… damn you github!
Name of my source code package says blender-trunk.tar.gz. I don’t see any other link on github for some other file???
They should’ve put >>> HERE’S THE DYNTOPO SOURCE <<< or something :D
So… can I get the source using some console tool or something? (maybe my browser just displays the web page badly)
That’s because you built the Blender-trunk branch. You need to build the Dyntopo-Slim branch. Do:
$ cd /path/to/blender/sourcecode
$ git checkout dyntopo-slim
$ make
To list all the branches available, do:
$ git branch -a
To avoid merge conflicts (from other branches) when you pull from git, I’ve found it easier to switch to trunk, delete the old dyntopo-slim temp, git pull, then checkout dyntopo-slim again before building. This may not be needed, or the best way to do it, but it works good for me. The commands for that look like:
$ git checkout trunk
$ git branch -D dyntopo-slim (if “working” dyntopo-slim exists)
$ git pull
$ git checkout dyntopo-slim (creates “working” copy of dyntopo)
$ make
Hope that helps.
I’m not used to fetching theese sources like this, please give me a hand.
I tried git clone with some links, but I get:
…/info/refs not found: did you run git update-server-info on the server?
Or:
Username for ‘http://github.com’:
Password for ‘http://github.com’:
and so on.
PhiliWitte, as for your commands, I dont have any .git file which is apparently needed.
I know it’s dumb, but could someone please just upload the source somewhere so I can download and build it?
How do I download the dyntopo-slim files?
I’m confused, I thought you had already cloned and built Blender from source? To clone a repo from github, just run (in this case, Blender):
$ git clone git://github.com/nicholasbishop/blender.git
That will create a new directory which all the source code in it. From there, just ‘cd’ into the directory and run the commands in my comment above. There’s no need for a user/password or anything like that (that’s only needed to push changed back up to the git server).
That will download the trunk.
I need the dyntopo-slim files…
please help me!
i don’t think this is the right place to discuss such things, better go to irc at freenode.org and ask at #blendersculpt or at blenderartists.org dyntopo thread
but just as a quick ask:
you have to cd to your cloned git folder and do git checkout dyntopo-slim
that would switch you to dyntopo branch
It pulls down all the code, Trunk and Dyntopo-Slim.. you just need to ‘checkout’ the Dyntopo branch before building. Git branches store only the files modified, so you need all the trunk code in order to build Dyntopo.
Just ‘git clone’ Nicholas’s Blender repo (as I describe in my previous post), then follow the steps in my original post to Duy3 and you should be good.
While there is still enough width in this text column…
thank you for the link, I should’ve figured to point it to the .svn file, but again, I don’t usualy deal with this kind of thing. I’t downloading right now so after that I guess the git checkout command should work fine.
git command not found
-sully
You need ‘git’, and a lot of other packages installed to be able to build Blender from source. Take a look at the official Building Blender Wiki:
http://wiki.blender.org/index.php/Dev:Doc/New_Developer_Env
However it’s a bit in-depth. If you’re completely unfamiliar with building code, and just want Dyntopo to work, I recommend simply trying to run a pre-built version from graphicall.org:
http://graphicall.org/?keywords=dyntopo-slim
Hi~ Nicholas Bishop~
Thanks for u Greater/Creative tool!
I have a suggest for Adding a tool for pickup The average-detail-size under mouse on mesh.
Then~ For changing detail-size We don’t have to move head to ToolBar.
Thanks！
+1
Hello!, first of all thank you for sharing your talent with the world!, as i don´t know how to code, i can make an icon if you want, but, can i ask for a link to the one used so far? so i can download it, get the dimensions and file extension, and also you need on/off states of the icon? or with one button icon is enough?
Thanks for the offer, but I now have an icon for dyntopo from Julio Iglesias.
Found teensy tiny little bug. The handle in the top right corner of the viewport (the one used to split windows) gets brighter as you go along with the stroke. Seems to be getting redrawn on top of itself. It only happens with the n-panel closed, and doesn’t happen in trunk.
Ubuntu 12.10 x64, nvidia stable drivers.
About the crashes on exiting dyntopo mode, now that I installed linux and built it myself, the crashes just don’t happen. Odd.
Are you sure the top-right handle doesn’t get brighter in trunk? For me this always happens (just confirmed in the 2.64a and 2.64 releases.)
I had briefly tested with the file I had open in trunk at the time and the mesh had a modifier on it. It seems the bug doesn’t happen on meshes that have modifiers on them, but does happen in trunk. Sorry for the confusion!
Hi! I’ve successfully built this latest version today.
I’ve been sculpting for couple of hours, and after one lucky save I pressed undo button but the whole mesh went to hell. Then I saved again the bad mesh. The action I did was pressing undo. The action before that was clay brush. If I could help somehow besides from sending the save files I’ll be willing to do so.
Here’s what happened:
http://postimage.org/image/7h5wipf1v/
I hope this helps.
Yay I managed to reproduce it by loading the save, brushing some with clay, saving to a different file and then pressing ctrl+z.
It seems to be the case with and file. Just save under different name and hit ctrl+z.
you should upload the file so Nicholas can see exactly what’s going on.
I’ve had random polygonal mess ups before but nothing like what happens in your image. It might also be nice to know your hardware configuration and drivers.
https://rapidshare.com/files/3235577285/blends_and_system_conf.tar.gz
There’s two files and my configuration text file in the archive.
In any case, each time I press undo immediately after saving this happens.
Oops I named the files pre_crash and post_crash.
There’s no crash, only this mess with the polygons. As if some of them were scaled by -1 around the center.
Not a great priority I guess, since this happens just for freshly saved files.
Thanks for the bug report, I am able to reproduce it and will track it here:
https://github.com/nicholasbishop/blender/issues/12
Hey man, in my opinion its a fully workable code and I don’t see why it’s not in the main release of blender. I didn’t got it to crash in any way.
But maybe because I’ve built the blender without game engine, cycles, and pretty much everything else. Is there any suggestions to try dyntopo with something else built within blender and test that? I don’t know what other code might affect the dyntopo code?
I can reproduce this bug under linux 64b (recent build made by James yesterday). This happends only when Dynatopo is enabled.
Hi Nicholas,
I think I’ve re-downloaded dyntopo-slim about 3 times now, and yet every time I pull updates I get merge conflicts :(
I always first get the source, then checkout dyntopo-slim, then compile; which works. It’s just when I update the source that I get merge conflicts, and that causes build errors.
What should I do?
(P.S, I’m not really a sculptor, but dyntopo has made it very enjoyable. Thanks :D)
To avoid conflicts, try this:
git checkout trunk
git branch -D dyntopo-slim
git pull
git checkout dyntopo-slim
Thanks for the advice, should I do that before each update?
yes, you need to run those commands every time you want to pull updated code from github. If you accidentally forget to switch to trunk and delete the dyntopo-slim working branch before running ‘$ git pull’ (as Nicholas illustrates above), then you’ll (most likely) get stuck in a “you need to resolve conflicts…” state. If that happens, simple run:
$ git reset –hard HEAD
and then run the commands Nicholas listed.
Thanks guys, I just tested it and it works!
:D
Thanks for your help, time and effort for the dyntopo.
I believe i found a bug in dyntopo. I have a windows 7 64-bits The build is from Vitok1, i believe.
So after sculpting with dyntopo i save the file with ctrl+s and just after that i did ctrl+z to undo, the sculpted mesh just goes crazy and another ctrl+z the mesh looks like somebody has removed some faces.
Oops! I just realize that the post before mine was about it.