- User Since
- May 27 2013, 3:25 PM (324 w, 5 d)
Nov 10 2018
Feb 27 2018
Feb 24 2018
Dec 12 2017
This should be deleted. I was not intending it to push to the server.
Feb 18 2017
Feb 10 2017
I'm also seeing the same result and have bisected to rBd6cf28c5e15739f864fbf04614c2a50708b4b152
Oct 24 2016
May 4 2016
Apparently today really isn't my day. I couldn't reproduce it, even after cleaning out the repo. It took me looking through my bash history to find out that, yes, I was using py 2.7... only to activate my venv and try again. Obviously I'm a colossal idiot when I'm tired. I can't close or delete the patch. Sorry for wasting your time.
I build from source, so I use a virtual environment pointing to the python build from install_deps.sh (3.5.1).
May 3 2016
Mar 8 2016
Feb 26 2016
Feb 25 2016
Perhaps it would be good to document such behavior, then. Addons register keys, but they are not exported, despite not being part of the defaults. It also seems that entire categories are exported if only one entry is changed. Overall this behavior is really misleading and poorly documented. I will try to set up docs locally to submit changes there.
I forgot to link in the original post, but the wiki also has a section about exporting/importing, but it's very brief doesn't describe much of anything.
Julian directed me to this task after a brief exchange about the tools region on the interface list, so I wanted to make sure this is exactly what you intended, rather than just the viewport regions. I absolutely agree with consistency and I'm fine with big changes.
I'm not arguing the UP toggle; I'm fine with having a toggle. However, is the plan to make it consistent across the entire UI or only the tools and properties region in the 3D View? or other editors? What is the scope of the change? I want it defined as part of the design, not a byproduct of one use-case.
Wouldn't this also change how the properties editor works as well? While I wouldn't necessarily be opposed to a change in the tools and properties regions, I wouldn't be comfortable changing the properties editor to conform.
Feb 14 2016
Jan 27 2016
Seems to work for me now. Thanks!
Jan 14 2016
@Sergey Sharybin (sergey) Any updates with this? I can't commit, so it's just been sitting here doing nothing.
Dec 3 2015
Dec 2 2015
Nov 29 2015
I updated install_deps.sh to /opt/lib/opensubdiv pathing as suggested by @Sergey Sharybin (sergey) and removed edits on the cmake modules. I've tested with a fresh deps build and it seems to run smoothly, although it would be good to run by more experienced eyes to make sure. I've included an attached build log for you to make sure.
Nov 27 2015
Oct 28 2015
Just to follow up, this seems to be caused by the animation nodes package. I'll bring it up with Jackes when I get the chance.
Oct 19 2015
Oct 17 2015
Sep 14 2015
This is a simple example file. It is a sphere duped through dupliverts. Press ctrl-shift-A to make dupes real, then search for "make single user" and select "all" to turn all objects into single user. You'll see that mesh data does not become unique, and because of that, shapekeys are not unique, etc.
Sep 5 2015
If there is to be a separation of driver value and timeline, is it too much to do a separate or integrated visual aid for driver value change? Perhaps it would be best to just stick with setting keys on the driving attribute over time, but then you get stuck with frame integer increments. Maybe the single toggle would come in handy here? I agree with the proposal, but it seems to me I'm overthinking.
Apr 20 2015
This is a comp screenshot of the two areas. If you copy/paste the hex value from viewport GP to prefs GP, the RGB values are:
Updating to driver 349.16 did not change any behavior. My guess is it's on the blender side.
Mar 24 2015
Mar 18 2015
The reason the issue goes away in the appended file is because the camera clipping near distance is set to 0.1 whereas the original file has it set to 0.001. If you set your clipping near distance in the original file to 0.1 as well, the issue goes away. This is a well-known issue with openGL and cameras. As someone who likes to push buttons, I can understand why you wouldn't expect this behavior, but I wouldn't call this a bug; you just need to set up your camera properly for your scene.
I can confirm I see a significant slowdown in RC2/master. My results are here: http://www.blenderartists.org/forum/showthread.php?365655-Slow-Cloth-Simulation-in-2-74&p=2837376&viewfull=1#post2837376
Feb 3 2015
Feb 9 2014
@Sergey Sharybin (sergey) I don't have time to dedicate to personal projects anymore. Whatever is making buildbot respect symlinks is entirely unknown to me; I'm not a coder by any definition. All I can say is that it should keep doing what it's doing. The build environments on the official builder machine is unknown to me. Maybe it has to do with MSVC 2008 express w/ hack versus MSVC 2008 Pro. Another reason might be that symlink explorer extension I use. Something I would try is to build with express w/ hack before installing the extension, then installing it and building again. The extension may change some deeper underlying configuration in Windows to allow easier symlink creation that I'm unaware of. The type of link also makes a difference. The extension allows any number of symlink types, from symlink clones to smart copies to junctions. Someone would have to experiment with each type and see how Blender behaves when it comes across each one (and also create them without the extension through the terminal).
Dec 9 2013
I'm curious how this would play into final rendering, such as motion blur and sub-frame animation. I know it's possible to export a cache in sub-frame increments, but how motion blur will work is beyond me. Does Alembic have any provisions for this or will it be entirely up to Blender (or other software of preference) to interpret and interpolate between cache steps?
Dec 1 2013
Nov 26 2013
I can't say I have done anything special in setting up my builder. My current Blender setup is entirely run from my B drive, simply to keep it all contained. Buildbot is entirely maintained and run by a separate user, "buildbot." The only caveat was that I didn't allocate enough space on my B drive to have multiple copies of libs; I symlinked a single copy of each lib into their own buildbot directory to save space. Each BB directory has its own source, though.