- User Since
- Feb 23 2012, 2:42 PM (369 w, 22 h)
Nov 22 2015
Aug 21 2015
Just reporting to confirm that it's working great (and ambient occlusion is working again too) in today's build blender-2.75-10edaff-win32.zip
Thank you for your work.
Aug 20 2015
You're right, after launching blender with --d , i see in the console when opening that blend :
just tested on blender-2.75-a6457f2-win32.zip
Aug 19 2015
Sorry to re-open, but since it has been fixed, i noticed in today (and yesterday too) build, material view is broken again.
Aug 10 2015
Aug 5 2015
Psy-Fi mentionned on the BA board :
Aug 4 2015
Just reporting that i tested on today's buildbot ( blender-2.75-23f5407-win32.zip ) and i confirm that it's now working greatly.
Aug 2 2015
I do not know if your patch fixing the problem has been included in Blender since you submitted it , but i tried today's buildbot ( blender-2.75-3b4a8f1-win32.zip ) and unfortunately the problem is still present, the locked planes are ignored if sculpt tiling is enabled.
Jul 31 2015
I do not know if it's because of the "dirty" solution or if it is what you mean by "TODO" in the fix.
But in case you aren't already aware, while the brushes after that fix do not horribly destroy the meshes where you stroke fortunately, even with the fix they are still not working correctly with "Area Plane" locked when you use tiling, in fact they work as the user had not locked the "Area Plane".
Just posting to confirm after testing on blender-2.75-6b7313b-win32.zip from today's buildbot (folder named Blender-2.75.0-git.6b7313b-AMD64) that it is working correctly in several of my material view tests.
Jul 27 2015
Hello, just wanted to report that i tried today's cmake for win32 (as the other win32 build seems to have disappeared) and it worked great, thanks for the fix.
Jul 25 2015
Jul 19 2015
Forgot to mention, but it may be important :
May 19 2015
Nov 30 2014
Nov 28 2014
I managed to get a friend that had the same OS as me to try and he didn't observed much difference between the 2 zoom methods in term of CPU usage.
The bigger difference was that his system has 3 cores while i have 2 but unsure at that point if it's part of the problem.
Nov 26 2014
Oct 1 2014
Thanks, i had looked around a bit after my last post and noticed that intel had ceased support in 2012 for xp/g41, way before microsoft, so it's not much of a surprise if they have bugs or incomplete support for their opengl 2.1
At least i know it's the driver now, i was wondering if i had something else broken with my Blender settings.
I'll just have to avoid pressing accidentally Z next time i texture paint :)
Sep 30 2014
On the case i reported
Sep 25 2014
posting there as merged
little update, i managed to get a friend with the same OS but with a ATI Radeon HD4850
And when he press Z in texture paint mode while in Blender Render, it does not crash for him.
If i switch to bounding box instead of pressing Z , same crash, other display mode works correctly (still will not crash if i am in Cycles render mode instead of Blender render mode)
Sep 24 2014
The very odd thing is that it does not crash on Cycles
Here it is :
Sep 23 2014
Aug 5 2014
I confirm, today's blender-2.71-6b6ea04-win32 works without a problem.
Thank you for your work
Aug 2 2014
Jul 30 2014
Hello, if it can help, in that post on the blenderartist Looptool thread, the user Pink Vertex suggested a solution, that from testing a bit in Blender seems to work :
Jul 29 2014
Thanks, with threaded sculpt disabled, the CPU usage is much better.
Sorry to re-open but it looks like the problem is still there
Jul 27 2014
I confirm it on my end too on win32 , 2.71 and 2.71 buildbot eat 100% of CPU on any sculpt stroke ! on a sculpt i had started back in 2.70.
Jul 26 2014
Maybe you do not have the msvc 2013 redistributable that is required to run 2.71 and later, you can install it from them on XP :
Jul 25 2014
Thanks to Eppo pointing it, it looks like that problem can be avoided by scaling up the mesh, it looks like when edges are small (i mean something like 0.0x blender units, x being a number ) , the chances of the doubled vertices at a cut will increase a lot.
Jul 24 2014
Jul 20 2014
Sorry to re-open, but after having tried a build from buildbot :
Jun 21 2014
I meant Blender RC2 for the problem described, not RC1 sorry
Jun 13 2014
If it can help, here's one i got recently with a non serious sculpt fortunately with a recent buildbot version, e8c63ca .
It's a variant of the "spike" bug reported several times, variant as it's not a big spike, but similar because it will never go away once it has started happening :
Jun 8 2014
from the dev meeting you certainly followed :
I know you guys are moving away from it the "legacy" version but it looks like it's just back at that error again
May 11 2014
May 8 2014
Back to the original bug, as the "Error setting option flags2 to value fastskip" is very likely a different one.
I tried the latest vs2008 buildbot on win32, blender-2.70-d964bad-win32 , ( after renaming the dll to make it work as mentionned in my last post of that report https://developer.blender.org/T39495 ) and i found out that following exactly the steps i mentionned on the original bug report (and that previously insta-crashed Blender on "stable" 2.70a and further vs2008 builbots) is now delivering the wanted result without crashing now.
I know you guys are dropping vs2008 builds , but just for completion of this bug report in case it popup one day on future builds i found out that :
May 3 2014
looks like it's related to the vc2008 version of 2.70a stable then, i wonder what was different from the 2.70 stable (that unless i'm mistaken was vc2008 too).
Apr 28 2014
Some update as i think this could be useful as it shows something strange to add on that bug :
Apr 27 2014
I can confirm the same problem , just tried on 2.70a stable for win32 and on blender-2.70-1e39046-win32-vc12, and pressing G then constraining to X and the vertice will not snap on the edge , the little target circle will snap but the vertice will not at all.
Apr 26 2014
As the win32 vc2012 is now up to date on the buildbot, i could then give a test to today's blender-2.70-1e39046-win32-vc12
And it worked without a problem , no missing dll message.
Apr 24 2014
Yes, i just tried the blender-2.70-36defb7-win32-vc12 from the buildbot ( that is older as it is the 19 april , while the vc2008 version that is newer is broken since the 14 or 15 april ) and it works without the missing dll error message.
win32 buildbot version is still broken, same missing dll with today's blender-2.70-3442a65-win32
Apr 22 2014
the problem is not about finding a workaround with different format as it's not a support question but a bug report, the problem is that this is a very bad regression bug that lead into a crash on 32bits builds (confirmed by you not having a problem with it on 64bits ones) on the stable 2.70a release, while it worked perfectly on the stable 2.70 one.
If it's working for you, to confirm that this nasty regression bug is affecting 32bits only, are you using the 64bits version of Blender on your system ?
Apr 20 2014
thanks for trying, so it looks like this 2.70a nasty regression is affecting 32 bits builds only.
Apr 19 2014
I'm not sure if anyone is still checking this report but the win32 is still missing the dll in
Apr 15 2014
And it's broken again starting with the latest build bot i just tried :
Apr 13 2014
after testing more, it looks like when indeed you use old blender version the bug disappear, but in appearance only, because it is in fact not buggy at Margin = 0
While it is immediately buggy at Margin = 0 with default factory settings.
On a Blenderartist thread thanks to some users helping, some odd behaviour of that bug has been noticed, some people actually observed only the correct behaviour in 2.70a
Apr 12 2014
very bad, that nasty bug is now in official 2.70a too , the smart uv project is then not trustable anymore for unwrapping and texturing.
Apr 6 2014
I just downloaded and tried blender-2.70-1bd3922-win32 from the buildbot and it does not throw anymore the missing dll message, it works great.
Apr 4 2014
Yes, if that change is intentional making it as an option in F6 is really needed, as while it would be indeed ok for texture painting, for assigning an existing texture it would only lead into nasty image distorsion on the object surfaces.
forgot to add screenshots :
Mar 29 2014
reporting it there as my bug report was merged in this one
testing with a libiconv-2.dll from dll-files.com , blender then popup an error about missing avutil-51.dll , that if i add to blender always from the same dll website allow blender to run apparently without a problem.
Mar 28 2014
Well spotted !
I completely forgot that a 360 spin duplicate will always lead into doubled result on the original mesh and required a w -> remove double
Mar 26 2014
Mar 23 2014
Update on this, thanks to Michalis pointing it to me on the Blenderartist dedicaced Dyntopo thread.
I can reproduce it on my xp sp3 with the provided blend.
Some important additional note i found today while testing more :
Mar 22 2014
Mar 20 2014
just remembered an old bug report about the alpha settings in multitexture not existing in the Material panel of Blender Render, but only existing in the Material panel of Blender Game, and still the BGE material alpha settings having an influence on the Blender Render mode.
looks like i can't edit what i wrote, so
Go into front Right View (Numpad 3) in Edit Mode
Mar 14 2014
As i could reproduce the same problem with a dyntopo dense mesh , i'm adding more informations :
Mar 13 2014
looks like Michalis reported it faster than me :