Just a tech-minded artist looking to use blender for webcomic production. I have some talent in the art of breaking this under controlled conditions (and sometimes, not so controlled).
- User Since
- May 3 2013, 6:26 PM (324 w, 19 h)
Dec 8 2018
Aug 29 2016
I found a simple workaround for this issue: hooking up drivers to the kink's Amplitude and Frequency properties, and in the driver multiply their desired values by the model's scale.
Aug 28 2016
Apr 14 2016
@Sergey Sharybin (sergey) Thanks for the tip. Though, nothing showed up on the memory test. Just a bit ago though, while booting up to my Windows drive, my motherboard's utility software gave me a warning that one of my chassis fans (one on top of the case, directly above the CPU) was not running. I fiddled with the connections and fixed that. The problem doesn't seem to happen anymore.
Apr 12 2016
Please close this report. I've encountered this issue outside of blender (youtube html5), so I think I can reasonably conclude that my computer is developing hardware problems.
I booted up with my Windows 8 drive, and my computer still locked up after fiddling around in rendered viewport. So, the issue is not specific to Linux/Ubuntu.
PS: I just tested this issue with 12e4da6, and found that the issue sort of does occur, but instead of crashing/freezing the entire computer, it just crashes blender.
Jan 25 2016
I think I'll just turn spatial splits off then. A quick test render on an urban scene I've been working on showed a 20-30 second reduction in render time with spatial splits disabled, and a small reduction in memory usage.
As a note, I was able to partially alleviate the problem by dividing the hair-covered mesh into quarters, and then splitting each quarter off into a separate group. This brought the BVH build time for instances down closer to what it was for the originals.
Jan 16 2016
@Mircea Kitsune (mirceakitsune): Read back a few posts. This branch has been abandoned by Lukas Stockner due to some problems with the implementation, and he said that he would be looking at some alternatives for reducing rendering times.
@Peter Boos (PGTART): It will compile under the 2.76 release. I have not tried compiling it under the 2.76a or 2.76b release. Getting it to compile under the current blender would require you to delve into C++ coding, rather than git. I may take a stab at updating the patch myself in a day or two, though I don't know how successful I would be at it since my skill with C++ is lacking.
Jan 15 2016
You know, an idea occurs to me for something that could help make this work better, by reducing the splotchiness.
Jan 10 2016
Nov 27 2015
One of these days I'll learn to to read slower, lol.
This change may actually cause problems for me. I had observed an issue on the Refraction BSDF where a few tiles on the refractive surface would take a few orders of magnitude longer to render when their facing was almost perpendicular to the camera, and they would often take much longer to render than the rest of the image.
Aug 20 2015
@Campbell Barton (campbellbarton) - Mtree, huh? You know I had a funny feeling that this issue was related to the other subdivision-related crash report I filed...
Aug 19 2015
Aug 18 2015
Aug 16 2015
This issue seems to still be occuring as of build 19cc75d
Aug 11 2015
For some reason, I had the subsurf modifier disabled for preview render. After turning it on, the crash now begins to occur when the viewport is set to Rendered mode.
Well, that's extra strange, then.
Aug 10 2015
Further info: the fur in the example file I gave was not actually using the material with the texture. Setting the correct material to the hair system still reproduces the issue, and further testing reveals that simply having a textured material present in the object's materials will reproduce the issue, whether or not that material is used.
After posting this, I ran a quick test. It appears that when the viewport is set to Preview rendering mode, the crash does not occur. It only seems to happen when I execute a final render.
Would it be possible to update this? The last working build I have for this is a development version of 2.75, and that build is on a revision with a showstopper bug with packed textures that got fixed in later revisions.
Jun 2 2015
I apologize for being late replying to this. Re-running install_deps.sh does fix the collada issue. However, the resulting binary was crashing when rendering most scenes (and I mean it crashed immediately the moment the render begins, and nothing appears).
May 27 2015
I'm seeing the same issue as mib2merlin. On another note, I looked into util_importance.cpp and it looks like avgVariance is not used anywhere.
Apr 29 2015
No programs will open it? If it won't open even in blender, that could be an additional problem for Carlo.
Apr 28 2015
Anyways, feel free to close the report. I had a misunderstanding of what the light portals were used for.
What do you mean default size? I made sure to scale it up because I assumed that was necesary! Even reopening the original file just now, I can see that the area lamp is the correct size (though the viewport has to be set to wireframe in order to see it).
Okay. I guess I don't really understand what anisotropy does, then.
Apr 27 2015
@Thomas Dinges (dingto): There was no OSL problem. It had simply been a while since I had reason to activate it, and I forgot that it was a checkbox under CPU mode, and mistakenly believed it to be in the device menu dropdown.
This no longer patches against the current master.
Apr 24 2015
Mar 20 2015
Please close this issue. I figured out the problem: at some point I had accidentally set Duplication:Faces on the child object.
Feb 27 2015
I was able to repro the issue on both CPU and GPU/CUDA.
Feb 24 2015
@Sergey Sharybin (sergey): Well, that's the thing. As far as I know, all of the settings between the two are the same. The only one that is different is the child hair counts (Display vs Render), but those are almost always different and usually work fine.
I see it on both final render and in rendered viewport.
Another note, this issue may be related to T43694, which has the same problem with hair clumps stretching towards the scene center, by whatever percentage the clumpiness is set to. Both may be symptoms of a common underlying bug.
My apologies, I hit submit by accident.
Feb 22 2015
Feb 21 2015
I am finding that when Progressive Refine is enabled, the render will stop after a few seconds and remain frozen. This error is unrecoverable, and requires me to force-kill blender. The problem stops when I disable the Save Buffers option.
Feb 18 2015
This issue can be closed for now. It no longer occurs under the current builds from buildbot, fda1198
Curiously, something with my blender configuration prevents the crash: it only repros for me with a factory reset, the opposite of what I was seeing in T43714.
Still repros with softwaregl. However, when I do a factory reset (by renaming the settings folder), the file actually crashes when opened, both with normal blender and with softwaregl. The crash doesn't occur on my debug build though, which is about a week older than the buildbot build I had used.
I don't even know what the correct name is. Area, I guess? When I was talking about panels, I was referring to things like 3D View, Timeline, and UV/Image Editor.
Okay, got the backtraces.
Since the issue will not repro for any developers, I am compiling a debug build of blender so that I can obtain a backtrace through gdb.
@Julian Eisel (Severin): I used one of the buildbot builds for testing this one.
I already put repro steps above in the initial report.
Further note, I do not know what steps, if any, are required in order to redo the bug. The issue came out of nowhere, but does not occur in 2.73 release, and the startup.blend I supplied has not been modified since November 29th.
@Campbell Barton (campbellbarton) Issue does not repro from factory reset. However, after a factory reset, the issue repros again when I load up my old default blender scene.
Feb 17 2015
Still occurs with softwaregl. What OS were you using, and was it 32bit or 64bit?
Feb 16 2015
This bug was holding up a project of mine, however I have come up with a usable workaround.
A snapshot of the bug, in case it does not repro on other system's for some reason:
Feb 13 2015
Feb 8 2015
@Bastien Montagne (mont29) - Yeah, that's why I said it would be simple "in theory". And because I know that nothing is truly simple with programming, lol.
Feb 7 2015
Feb 2 2015
Since the behavior is intentional, could the unintended side-effect of it be fixed instead? IE: could duplifaces be fixed/adjusted to account for the mirror modifier?
Jan 30 2015
Aye, glad to help. I think that's three for three on crashes I've reported since 2.73.
Just recompiled after updating to master, and the issue no longer repros :-)
Never mind, I realized that it was writing the file internal to the .blend file.
Yes, I've been using Texblur.blend for these tests. The backtrace was also with OSL disabled, as the build was not compiled with OSL support.
Actually, just to double check in case the report was misread, are you doing a Render, or are you setting the viewport shading to rendered? Because the issue only repros with rendered viewport.
Give me ten or fifteen minutes. Recompiling at the moment.
Yes, it happens with or without OSL. The only place the crash does not occur is with GPU rendering.
Okay, I got gbd figured out. Here's the backtrace:
I just finished compiling a debug build. I have not yet figured out how to use gdb, however the debug build seems to provide some output when the crash occurs:
Jan 29 2015
@Kévin Dietrich (kevindietrich) I am using CPU rendering for it, the issue does not repro under GPU mode. I tested again with the most recent build off of builderbot ( d434815 ) and it still repros.
In case it's useful, here is the command line output I received during the crash:
Last paragraph before the repro steps should be ignored, forgot to delete it after rewriting the description.
Jan 20 2015
Deleted my blender source directory entirely, and redownloaded everything from git so that I had a clean slate. Issue no longer repros.
Jan 18 2015
For the nightly, the hash is 6e97db7. For the build I compiled myself (where the issue still repros partially), there is no hash. This is the output from git on the command line:
Issue repros on my build from just a couple hours ago that was compiled fresh off of git. However, the issue does not repro at all on the nightly I just downloaded.
@Bastien Montagne (mont29): I just freshly compiled blender from git this morning. The crash no longer occurs with the original model(s) I discovered it on. However, it continues to occur with a slight variation on the repro steps I posted above:
Jan 17 2015
Further testing, and with new repro steps. It'll occur on ANYTHING you use Transfer Weights on.
Actually, I should point out that the problem begins with using the Transfer Weights function in weight painting mode.
@Sergey Sharybin (sergey): Check my previous comment, before yours.
Okay, I've made another repro file. This one does not produce the crash, but rather sets the stage for the trigger conditions. For this I have used a different model off of blendswap, since I do not yet intend for the character models to be available in public.
I don't think the problem is so much the file, but rather it may be some kind of mishandling with weight painting or deformation? The crash occurs after I transferred weights from one model to the problem model. But when I instead just created the DEF-head group and then set it to 100% on all vertices, there were no problems.