Page MenuHome

Garry R. Osgood (grosgood)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 31 2018, 10:30 PM (78 w, 4 d)

Recent Activity

Fri, Jun 19

Garry R. Osgood (grosgood) changed the status of T78003: Blender crashes by toggling between object and environment properties rapidly from Needs Triage to Needs Information from User.

@Juan Binafa (Binafa)
Forgive my pedantry; you write English quite well, but by 'Clip,' I think you mean 'Click'.
And - sorry - with 2.90.0 Alpha, branch: master, commit date: 2020-06-18 19:05, hash: b89898cbd381, type: Release(Gentoo Linux - eight commits after yours) all good here with a couple dozen passes using various types of curves and surfaces.

Fri, Jun 19, 12:19 AM · BF Blender

Wed, Jun 10

Garry R. Osgood (grosgood) abandoned D7968: A Patch to Address Task T77195.

@Campbell Barton (campbellbarton)

Are there still cases where this patch is needed?

I think we're good.
Thank you for all your good work!
Tidying up here...

Wed, Jun 10, 2:29 PM · Modeling

Tue, Jun 9

Garry R. Osgood (grosgood) requested review of D7968: A Patch to Address Task T77195.
Tue, Jun 9, 4:19 PM · Modeling

Sun, Jun 7

Garry R. Osgood (grosgood) added a comment to T77195: Crash with Viewport measurements turned on.

TL;DR
Longish comment. If you must know, It appears to me that a reordering of processing stemming from the commit has put the reindexing of certain BM elements (BMLoops) rather late in the pipeline -- too late for the liking of the overlay drawing engine, which is tripping over un-indexed BMLoop elements: the gist of this bug.

Sun, Jun 7, 5:46 PM · EEVEE & Viewport, BF Blender

Jun 3 2020

Garry R. Osgood (grosgood) added a comment to T77195: Crash with Viewport measurements turned on.

Ah! Thank you! I stand corrected.

Jun 3 2020, 2:18 PM · EEVEE & Viewport, BF Blender
Garry R. Osgood (grosgood) updated subscribers of T77195: Crash with Viewport measurements turned on.

@Philipp Oeser (lichtwerk)
Thank you for the update of the task description. Slight correction: commit "deaff94...." (campbell) is the first version that goes into the `loo, not the last version that worked. The last version that worked was (one of ) your May 25 commits: rBdf8cbdc69645589b. See the git bisect log I attached: T77195_gitbisect.txt on my 01-June post. I'd fix it myself but I don't have the right Magickal Powers, it seems.

Jun 3 2020, 1:32 PM · EEVEE & Viewport, BF Blender

Jun 2 2020

Garry R. Osgood (grosgood) changed the status of T77271: blender crashes whenever I paint from Needs Triage to Needs Information from User.

Hi @oliver (MutaNtMANIAXE)
Welcome to the Blender bug tracker.
Forgive me, but I find your exact steps for others to reproduce the error not very exact. For example, between your first step: "Startup new project" and second, "unwrap", there are a bazillion possibilities. Are you unwrapping something with tens or hundreds of thousand polygons, with seams all over the place, or the Default Cube?
You're new here, welcome aboard, there happens to be an art to successful bug reporting covered in How to Report a Bug. The gist of it is that people who fix bugs (such as myself) may have little or no imagination (such as myself) and need very particular clues - as many as possible - to get a sense of where a problem may lie. Writing a good bug report can take a considerable amount of time on your part and it takes a certain amount of exact writing. That effort itself - the good bug report - is, in fact, a valuable contribution to the project and is much appreciated by people like me who try to fix things, even when I don't have much imagination. So here is what I appreciate you doing:

  1. Furnish an example file
  2. Attach your system information system-info.txt, available from the Blender Help -> Save Info File. Attach it, using the "cloud with upward pointing arrow" icon on the text box editor banner.
  3. Provide the exact steps that you take to get to the point where the crash takes place.
  4. Remember, you are writing to someone like myself with possibly little (I have no) imagination. Take nothing for granted. Don't assume the bug report reader is capable of reading anything between the lines.
  5. Write exactly. Vagueness is the enemy of good bug reports.

It is possible that what you are reporting has been covered already in T75452. Generally, before undertaking the writing of a good bug report, (which can burn away an hour or two of your life), check existing bugs to determine if what you are experience has already been reported. Should that be the case here, save yourself the effort of re-reporting that bug here, and just let us know that this bug seems a duplicate of that. Then you or one of the other triage people will close this one.

Jun 2 2020, 5:37 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T77195: Crash with Viewport measurements turned on.

Few notes:

  1. It is specifically the Face Area checkbox in the Viewport Overlays -> Measurement panel that triggers this bug. The setting of Edge Length is irrelevant. See line 392 of draw_manager_text.c. (v3d->overlay.edit_flag & V3D_OVERLAY_EDIT_FACE_AREA) == TRUE reflects the setting of this checkbox. That and BMFace f->hflag being odd - indicating the face is selected - sets the condition to render an area annotation on the face; that is when the suspect code runs.
  2. Should I deselect Face Area and then create a face, the operation succeeds. No surprise there: I am not asking for an area annotation so the suspect code does not run. Now, if I select Face Area, leaving the new face selected, the suspect code runs and the area annotation properly appears on the face without triggering the bug. That is because the BMLoop items in the BMFace f->l_first list all have their index members set to positive numbers and BM_elem_index_get() does not feed poly_to_tri_count() negative corner counts. See my notes in the post above.
Jun 2 2020, 2:53 PM · EEVEE & Viewport, BF Blender

Jun 1 2020

Garry R. Osgood (grosgood) added a comment to T77195: Crash with Viewport measurements turned on.

My apologies. Omitted methodology. Designation of 'good' and 'bad' for purposes of git bisect was to open the attached blend file: the default cube with its top face, Fn = {0.0, 0.0, 1.0}, removed and the four edges to form a new top face already selected.

  1. Hit 'f' to invoke MESH_OT_f2 and fill the top face in.
    1. If a face appeared, the binary at that commit was deemed 'good'
    2. If the assert in poly_to_tri_count() fired off instead, aborting the process, the binary at that commit was deemed 'bad'
  2. For each of the various commit points, built a full binary in an initially empty build directory. I built debug binaries so that the assert points were present.

Jun 1 2020, 4:42 PM · EEVEE & Viewport, BF Blender
Garry R. Osgood (grosgood) added a comment to T77195: Crash with Viewport measurements turned on.


A git bisect exercise leads me to rBdeaff945d0b965d1 by @Campbell Barton (campbellbarton) as the commit along the master branch where this bug is first manifest. Confirm that rBec26260132b49bf0, blender-v2.83-release does not exhibit this bug. I have not established any causality chains between the files changed by the good Mr. Barton's commit and the bug. That his commit involves edit-mesh -> mesh is suggestive - and that's all for now. See the attached for bisect details.

Jun 1 2020, 1:25 AM · EEVEE & Viewport, BF Blender

May 31 2020

Garry R. Osgood (grosgood) updated subscribers of T77195: Crash with Viewport measurements turned on.

@Robert Guetzkow (rjg):

This is likely related to the recent work on the overlay and viewport drawing.

May 31 2020, 4:02 PM · EEVEE & Viewport, BF Blender
Garry R. Osgood (grosgood) requested review of D7890: A Patch to Address Task T77106.
May 31 2020, 2:05 AM · Cycles

May 30 2020

Garry R. Osgood (grosgood) updated subscribers of T77106: Crash when baking diffuse map. (EXCEPTION_ACCESS_VIOLATION).

Commit rB799779d432309e518922d23e3a1d1b5baaece71d by @Lukas Stockner (lukasstockner97) on Jun 15 11:03:29 2018 +0200, as a part of D3479 added intern/cycles/kernel/svm/svm_ao.h. At line 69 of that file, (backtrace frame #1; see my first post) , scene_intersect_local(kg, &ray, NULL, sd->object, NULL, 0) is invoked with parameters local_isect=0x0 and lcg_state=0x0, thus setting the tripwire for this bug.

May 30 2020, 6:37 PM · Render & Cycles, BF Blender
Garry R. Osgood (grosgood) added a comment to T77106: Crash when baking diffuse map. (EXCEPTION_ACCESS_VIOLATION).

Some initial observations that may not be that relevant, but for the record:

  1. File -> External Data ->Report Missing Files reports as not found:
    1. filter.jpg
    2. filter_normals.png
    3. scratchesTEX.png
    4. tankEnd.png
  2. I find instruction 6: 'Make sure both "Direct" and "Indirect" lighting influence are deselected just leaving "Color"' to be irrelevant. In my case, I crash in the manner I cited in my previous post no matter how "Direct", "Indirect" or "Color" are set, so long as at least one flag is set.
May 30 2020, 3:45 PM · Render & Cycles, BF Blender
Garry R. Osgood (grosgood) closed T77162: Blender White Screen upon opening. as Resolved.

@Richie (brichard0625)
Thank you for the update! If you don't mind, I'll tidy up here. Take care, and thank you for the report.

May 30 2020, 12:29 AM · BF Blender

May 29 2020

Garry R. Osgood (grosgood) added a comment to T77106: Crash when baking diffuse map. (EXCEPTION_ACCESS_VIOLATION).

@Richard Antalik (ISS) declared:

Running debug build I got completely different stacktrace:

Not me. In the debug build I have here - see my attached sys-info.txt - I SEGV right here at @ intern/cycles/kernel/bvh.h, line 326; ditto with the release build.

#  else /* __KERNEL_OPTIX__ */
if (!scene_intersect_valid(ray)) {
  local_isect->num_hits = 0;  <-- 326: local_isect == 0!
  return false;
}

Here's the backtrace. Note the parameters being passed to ccl::scene_intersect_local has uninitialized pointers: lcg_state=0x0, local_object=0, local_isect=0x0,

(gdb) run
Starting program: /home/gosgood/git_repositories/build_linux_debug/bin/blender --debug-depsgraph /home/gosgood/Downloads/crashingBlend.blend 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
May 29 2020, 9:33 PM · Render & Cycles, BF Blender
Garry R. Osgood (grosgood) added a comment to T77162: Blender White Screen upon opening..

Shades of T75546 ?

all windows updates have been done

Did the white screen problem happen after or before this?

May 29 2020, 4:10 PM · BF Blender

Feb 24 2020

Garry R. Osgood (grosgood) updated subscribers of T73745: Particle Hair - brused hair segments can penetrate object despite Deflect Emitter option keeping the hair keys outside (causing trouble with dynamics).

The circumstances described here closely parallel T67958. In particular, the discussion in that report from Jan 27, 2020 onward, initiated by @Sybren A. Stüvel (sybren) after the new hair collision commit by @Luca Rood (LucaRood) ( rBd42a7bbd6ea57c69293d3bf978aae2c0e4241b57 ). Note remarks by @Germano Cavalcante (mano-wii) and @Sebastian Parborg (zeddb) regarding the Single Sided setting. Think that this report can be regarded as a duplicate of that.

Feb 24 2020, 2:53 PM · Nodes & Physics, BF Blender

Feb 17 2020

Garry R. Osgood (grosgood) added a comment to T73830: Blender complains that it cannot find "stdosl.h", despite it existing at "/usr/share/OSL/shaders/stdosl.h".

@Ray molenkamp (LazyDodo)
D6865 plays fine here. Completely uneventful. Ran a couple of builds, one Release and one Debug from empty build directories. Deleted CMakeCache.txt to make sure no strange symbols were floating around. Running ctest now; nothing out of the ordinary there either, up to now.
Current to: version: 2.83 (sub 3), branch: osl_rayfix, commit date: 2020-02-16 22:53, hash: f1a13b1ab8d6, type: Release

Feb 17 2020, 12:33 AM · BF Blender

Feb 16 2020

Garry R. Osgood (grosgood) added a comment to T73830: Blender complains that it cannot find "stdosl.h", despite it existing at "/usr/share/OSL/shaders/stdosl.h".

Different, unrelated alligators. These are pink. Alligators related to build systems are putrid green, have warts, big teeth. Pink ones have been dispatched now. Starting cleanup...

Feb 16 2020, 11:38 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T73830: Blender complains that it cannot find "stdosl.h", despite it existing at "/usr/share/OSL/shaders/stdosl.h".

Yep - but not now. up to neck in alligators again. Never can tell what comes out of a Brooklyn sewer. Late this evening probably; post results in the wee hours Monday (-5 UTC, less wee +1 UTC).
Thanks thee, for the rapid turnaround!

Feb 16 2020, 10:22 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T73830: Blender complains that it cannot find "stdosl.h", despite it existing at "/usr/share/OSL/shaders/stdosl.h".

Great! Don't forget this is a hack - unofficial, unsupported, probably radioactive. If you've followed my suggestion of creating a local git branch osl_fix to contain the patch, and you sit on the osl_fix branch to do your builds, then you've got (just a little) extra work to keep osl_fix aligned with master whenever you perform make update. See Creating Patches from Local Git Branches. The gist of it is: from osl_fix: git checkout master, make update, git checkout osl_fix, git rebase master. When the fix for this lands in master, you can just checkout master and do the update, then abandon osl_fix: git branch -D osl_fix.

Feb 16 2020, 8:19 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T73830: Blender complains that it cannot find "stdosl.h", despite it existing at "/usr/share/OSL/shaders/stdosl.h".

@Kyle (Valmar33)
Note that my workaround is peculiar to a Gentoo linux box; the steps need a certain amount of remapping to work on other distros. Fortunately, Arch is not that far removed from Gentoo.
In your case, introduce a CMake symbol via

Feb 16 2020, 2:13 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T73830: Blender complains that it cannot find "stdosl.h", despite it existing at "/usr/share/OSL/shaders/stdosl.h".

This bit me. Gentoo Linux here, with media-libs/osl-1.10.5 providing shaders in system folder /usr/include/OSL/shaders
For what it is worth, my workaround:

  1. Define in build directory CMakeCache.txt the symbol OSL_SHADER_DIR:PATH=/usr/include/OSL/shaders
  2. Modified blender/intern/cycles/kernel/shaders/CMakeLists.txt:
Feb 16 2020, 1:02 PM · BF Blender

Feb 13 2020

Garry R. Osgood (grosgood) added a comment to T73745: Particle Hair - brused hair segments can penetrate object despite Deflect Emitter option keeping the hair keys outside (causing trouble with dynamics).

Hi @Graham Cripps (craigievar)
Very clear instructions. Thank you for that. I think I followed them properly; look at the video I've attached. I cannot comb the hair tip through the single-face plane. Nor grabbing it via G and constraining it to follow the normal direction. Immaterial if the plane has been set up as a soft-body collision surface. The only way I could emulate your description of the bug was by deselecting Deflect Emitter. Turning that on again caused the hair tip to snap back to the positive normal side of the face.
Not sure what is going on at your end. It seems, for you, that Deflect Emitter is a no-op. Have you tried this on another machine?

Feb 13 2020, 3:44 AM · Nodes & Physics, BF Blender

Feb 12 2020

Garry R. Osgood (grosgood) added a comment to T73745: Particle Hair - brused hair segments can penetrate object despite Deflect Emitter option keeping the hair keys outside (causing trouble with dynamics).

comb the hair so that some hair tips penetrate the cube.

Neat trick. I can't do it (yet).
Agree with @Philipp Oeser (lichtwerk) - once a hair strand intersects host geometry, or hair strands intersect with each other, the hair will 'dance' under dynamics. Collision avoidance is in play. Pulling the hair tip though host geometry - that's the bug! - the circumstances under which that neat trick gets pulled. I can't do it yet with @Graham Cripps (craigievar) file or other files. Hmmm.

Feb 12 2020, 2:51 PM · Nodes & Physics, BF Blender

Feb 4 2020

Garry R. Osgood (grosgood) closed T73582: Iphone App Development Company | Techugo as Invalid.

@Mary Smith (marysmith996)
This web site is for reporting software bugs to Blender development.

Feb 4 2020, 1:07 PM

Jan 19 2020

Garry R. Osgood (grosgood) resigned from D6625: Initial improvements to doxygen config and structure. (T73140).

Sorry. Don't think that I have enough expertise in Doxygen as it is used in Blender to give you useful guidance or criticism. Thank you for thinking of me, though. As noted in T73140, I think @Campbell Barton (campbellbarton) is your better bet, if he has time.

Jan 19 2020, 11:06 PM · BF Blender (2.83), Documentation
Garry R. Osgood (grosgood) added a comment to T73140: Improve structure and visual identity in Doxygen comments in- and out -of code. Without structure ... entropy..

@Jonas Printzén (ZPU)

I am trying to bind the patch...

Forgive me. I am being dense over your terminology. I don't understand "bind the patch to this issue."
By "bind" do you mean "cross reference"? Perhaps it wasn't clear when you were in the midst of writing your last comment, but cross-references to the differential and this task were automatically created. Notations like Tnnnnn and Dnnnn are translated into HTML links to the target items. The 'book' icon in the banner of the text editor box, second from the right, places The Remarkup Reference Guide in another browser window. Then you can do all kinds of tricks in comments.

Jan 19 2020, 10:54 PM · Development Management, Documentation, BF Blender

Jan 16 2020

Garry R. Osgood (grosgood) added a comment to T73140: Improve structure and visual identity in Doxygen comments in- and out -of code. Without structure ... entropy..

@Jonas Printzén (ZPU)
Welcome to the project. I trust you have gone through the Build Blender exercise, have issued make doc_doxy and have been disenchanted with the result. In my opinion, this is a consequence of:

  1. Not using Doxygen to anywhere near its potential. You have essayed this task to address that
  2. The process of writing code level templates - Doxygen's input - have largely been bypassed by the protocols attending submitting a diff patch, which has a documentation component as well. This has effectively cut off the air supply to Doxygen.

As to the first point, I think this task is more at the design - todo level, meaning it is of the more ambitious sort. Cambell's suggestions about keeping your first efforts focused on a individually manageable effort is key: one or two pilot templates to illustrate Doxygen's potential to the community at large may be a more realistic scoping for this task. My second point is in play, because this community already has a way to deliver code documentation to the project through diff patches, which translate to commit messages and become metadata in the code repository - documentation about code, and automagically linked to the code in the repository. "And now you want us to write templates too??". may very well be the protest here. To that extent, the very idea of including templated code documentation would have to be argued here. That is beyond the scope of this task, but I think it is the 800 lb. gorilla currently sitting in the room.
However you scope this task, I hope you stay at it in some form or another. Literate programmers are few and far in between. Every project could use a couple.

Jan 16 2020, 1:49 PM · Development Management, Documentation, BF Blender

Jan 14 2020

Garry R. Osgood (grosgood) added a comment to D6531: Patch Proposed for T72490 - Collections: Exclude From View toggle causes segment violation.

@Clément Foucault (fclem)
Don't mind at all. `Twas a useful exercise for me. Thank you for all your good work.

Jan 14 2020, 6:22 PM

Jan 12 2020

Garry R. Osgood (grosgood) added inline comments to D6531: Patch Proposed for T72490 - Collections: Exclude From View toggle causes segment violation.
Jan 12 2020, 5:13 PM
Garry R. Osgood (grosgood) updated the diff for D6531: Patch Proposed for T72490 - Collections: Exclude From View toggle causes segment violation.

Cleanup per @Jeroen Bakker (jbakker) on Differential D6531: (1) tabs->spaces (2) <target field> == <query symbol>. Thank you for your style tips.

It seems to be incorrect state in the Object.

Yes. I think that 188: in_edit_mode = (ob->mode & OB_MODE_EDIT) && BKE_object_is_in_editmode(ob); resolves to true is not an anticipated circumstance with a prevailing pd->ctx_mode == CTX_MODE_OBJECT draw mode. This circumstance does not commonly arise, but toggling Exclude from View Layer does give rise to it. Why that is so is not entirely clear to me yet; I'm still quite junior in matters concerning the Blender object life cycle.

Jan 12 2020, 5:10 PM

Jan 5 2020

Garry R. Osgood (grosgood) created D6531: Patch Proposed for T72490 - Collections: Exclude From View toggle causes segment violation.
Jan 5 2020, 10:54 PM

Dec 25 2019

Garry R. Osgood (grosgood) removed a project from T62563: Hair Dynamics: cannot generate a valid particle cache: Tracker Curfew.

Removed Tracker Curfew tag per discussion between @Sybren A. Stüvel (sybren) and @Dalai Felinto (dfelinto): Re: Tracker curfew and developer.blender.org changes Identified as a known issue.

Dec 25 2019, 3:25 PM · Nodes & Physics, BF Blender
Garry R. Osgood (grosgood) changed the subtype of T62563: Hair Dynamics: cannot generate a valid particle cache from "Report" to "Known Issue".

Per Tracker Curfew, Tracker curfew and developer.blender.org changes and T71418
Known issue: user documentation could use a Note box to the effect that caches cannot be generated for dynamic hair by means of a final render ( Cntl + F12 ), but generating a cache for dynamic hair by previewing the animation in the view port or baking hair dynamics works. In these two cases the particle system interacts with a persistent depsgraph in Viewport mode. Render depsgraphs do not persist but are recreated frame-by-frame. The hair particle system has not been designed to interact with transient depsgraphs.

Dec 25 2019, 3:18 PM · Nodes & Physics, BF Blender

Dec 23 2019

Garry R. Osgood (grosgood) changed the status of T72634: Blender 2.81: Crash/Not Responding on Start Up from Unknown Status to Resolved.

Tidying up. Resolved by poster.

Dec 23 2019, 2:56 AM · BF Blender

Dec 22 2019

Garry R. Osgood (grosgood) updated the task description for T72490: Collections: Exclude From View toggle causes segment violation..
Dec 22 2019, 11:46 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T72490: Collections: Exclude From View toggle causes segment violation..

Debug notes. I won't revisit this until after the 25th, and, with a head full of grog, will need notes to recover context.

Dec 22 2019, 11:33 PM · BF Blender

Dec 20 2019

Garry R. Osgood (grosgood) added a comment to T72601: Blender Crashing On Startup (Blank Console and Blender White Screen).

Just for giggles: Does 2.79b play under Windows 10 for you?

Rendering something in console with --commands (Which worked, and output an image of said .blend file)

That's interesting. So if you add the command line switch equivalent to what @Robert Guetzkow (rjg) suggested: I think --debug_gpu (don't have blender here ATM to check, sorry) does blender run, exit, and leave diagnostic log files about your GPU?
Have faith. Lot of people are running Blender 2.8# under Windows 10; plausible that installation upgrade debris may still be in the way. Might be worthwhile to look around Blender Stack Exchange. Maybe start with: Blender Not Working in Windows 10, Any Suggestions?

Dec 20 2019, 3:12 PM · BF Blender

Dec 19 2019

Garry R. Osgood (grosgood) added a comment to T72580: External particles cache bug.

Similar to T70135.

Dec 19 2019, 6:39 PM · Nodes & Physics, BF Blender

Dec 18 2019

Garry R. Osgood (grosgood) added a comment to T72421: Fur particles exploding.

See T63225.
Hi @Robert (dundaglan),
Does this report add anything which was not conveyed through your earlier report? Thanks!

Dec 18 2019, 2:24 PM · BF Blender
Garry R. Osgood (grosgood) changed the status of T71473: Render Cycles,Evee from Unknown Status to Unknown Status.

@Pawal (BelCGFree)

Post the results of any investigations you do here. Thanks!

This has been quiet for over a month. Please feel free to reopen this report if you have anything further to add. Thank you!

Dec 18 2019, 1:11 PM · BF Blender

Dec 17 2019

Garry R. Osgood (grosgood) added a comment to T72426: Edit and switch collection crash.

Running with: Blender 2.82 (sub 5), Commit date: 2019-12-16 11:53, Hash rB8d16dc029e6c
In checking for similarities with T72490, I get @Armando Tello (ckat609) 's crash as well, with the following backtrace: See DRW_mesh_batch_cache_create_requested() at line 1206 for context.

Dec 17 2019, 1:21 AM · EEVEE & Viewport, BF Blender

Dec 16 2019

Garry R. Osgood (grosgood) updated the task description for T72490: Collections: Exclude From View toggle causes segment violation..
Dec 16 2019, 11:23 PM · BF Blender
Garry R. Osgood (grosgood) updated the task description for T72490: Collections: Exclude From View toggle causes segment violation..
Dec 16 2019, 10:50 PM · BF Blender
Garry R. Osgood (grosgood) updated the task description for T72490: Collections: Exclude From View toggle causes segment violation..
Dec 16 2019, 10:49 PM · BF Blender
Garry R. Osgood (grosgood) created T72490: Collections: Exclude From View toggle causes segment violation..
Dec 16 2019, 10:22 PM · BF Blender

Dec 14 2019

Garry R. Osgood (grosgood) added a comment to T72441: lookdev preview lighting spheres rendering pitch black.

Perhaps T72124.

Dec 14 2019, 10:24 AM · BF Blender

Nov 26 2019

Garry R. Osgood (grosgood) changed the status of T71903: Blender crashed after starting it. from Unknown Status to Unknown Status.

According to your system_info.txt, your system has a ATI Mobility Radeon HD 3430 graphics card. Released in July, 2008, it has TeraScale instruction set, and while that instruction set and architecture nominally supports OpenGL 3.3, the AMD TeraScale cards of that era have proven problematic with Blender 2.8x on Windows. See the discussion at Supported GPUs in Blender 2.80, in particular the AMD section. I'm sorry to report that your card falls into this problem area. You appear to have the latest driver for the card, but its release date was April, 2013 and was for Windows 7 or 8, I believe.

Nov 26 2019, 3:14 PM · BF Blender

Nov 24 2019

Garry R. Osgood (grosgood) updated subscribers of T71845: Error on importing .svg to Blender 2,81.

Looks like a manifestation of T71774 SVG Import Error recently fixed by @Sergey Sharybin (sergey). Compare backtrace, above, with that in the screenshot in SVG Import Error. Note that the screenshot reads from the bottom up with respect to the backtrace here.

Nov 24 2019, 4:58 PM · Add-ons (Community)
Garry R. Osgood (grosgood) updated subscribers of T71799: Hair Not Rendering in Cycles in 2.81.

So, to recap:

  1. CPU Rendering & Cycles - OK
  2. GPU Rendering & Cycles: NVIDIA/CUDA - OK
  3. GPU Rendering & Cycles: NVIDIA/OPTIX - Problems with some files (Specifically hair? Specifically with resized hair? Or are there other kinds of files (non-hair) with issues? [Edit - doubtful])
Nov 24 2019, 1:47 PM · BF Blender

Nov 23 2019

Garry R. Osgood (grosgood) added a comment to T71799: Hair Not Rendering in Cycles in 2.81.

@Joe Williamsen (jwilliamsen)
Not Reproducing It. Tested initially as-is, then moved the camera to get more detailed test images of the eye brows and eye lashes.
This machine

Nov 23 2019, 9:55 PM · BF Blender

Nov 15 2019

Garry R. Osgood (grosgood) updated subscribers of T71255: 2.82 Particle Hair not showing as expected in Cycles viewport/rendering due to optix rendering.

@Jonathan (Batty)
Good job narrowing this down!
Optix is a Work In Progress. This is the tracker task: T69800. I think you'll become subscribed to the tracker task by virtue of it being cited here.
I don't have Blender handy at the moment to compare what you see with the incomplete list, or if what you see looks like a bug. Unfortunately, even when I do have Blender handy, I won't be able to contribute much - I have AMD-based GPU cards. But if you have the time and inclination, you could keep an eye on Optix behavior and share your observations on that task. @Patrick Mours (pmoursnv) is the lead on Optix - Blender integration. I think you could be a good help shadow-testing his work. If you go to Manifest (left bar menu on the main page) and search on 'Optix' you'll find much of the current Optix activity.
Thank you again for your work in narrowing this down.
[Edit]
Ooops. Misspoke. You'd have to subscribe yourself to that task if you care to.

Nov 15 2019, 3:12 PM · Cycles, Physics, BF Blender

Nov 13 2019

Garry R. Osgood (grosgood) added a comment to T71459: Can't connect to Blender from a distant machine anymore.

Great! Thank you for sharing the results of your work. There is this post at the TeamViewer's blog that may be of interest: Gray screen instead of app interface when opened via TeamViewer, A Blender user that had similar experiences and may be of use to other people. If time permits, you might consider posting your solution in a high traffic Blender site such as Blender Artists Technical Support Forum. You can link back to your report here and save repeating yourself. Thanks in advance for sharing the knowledge!

Nov 13 2019, 12:45 PM · BF Blender

Nov 12 2019

Garry R. Osgood (grosgood) added a comment to T71255: 2.82 Particle Hair not showing as expected in Cycles viewport/rendering due to optix rendering.

Have you had any experience with Thomas Larsson's Diffeomorphic package? It purports to be a direct import from DAZ3D to Blender, bypassing COLLADA. I haven't used it, can't recommend it, can't pan it either, but suggest it in that it cuts COLLADA out of the problem space and may help you get off the dime in the larger project of getting your pipeline in order. Also, it can't hurt to open threads on Blender DevTalk and the technical support forum at Blender Artists. As you may gather, the bug reporter here concerns detailed fault reports. Sometimes, however what is really needed are insights from colleagues on the day-to-day use of Blender. Link back to this bug report so you don't have to repeat yourself too much. Take care!

Nov 12 2019, 2:30 PM · Cycles, Physics, BF Blender
Garry R. Osgood (grosgood) added a comment to T71459: Can't connect to Blender from a distant machine anymore.

they said it's blender's responsibility

The difficulty is with the word "it", Given the circumstances stated thus far in this bug report, this pronoun "it" represents a fairly vague set of circumstances - too vague in which to begin an investigation to isolate fault. In terms of detail, this bug report is on the level of "I lost my car keys in Central Park." What is needed is more precise information on time and place. The art of bug reporting entails narrowing the realm of possible search areas with specific facts that eliminate places to look, and the bug reporter's efforts along those lines actually represents a material contribution to the project - and to solving the bug.

Nov 12 2019, 11:55 AM · BF Blender
Garry R. Osgood (grosgood) added a comment to T71473: Render Cycles,Evee .

Hi Pawal,
I couldn't reproduce your crashes, but suspect that memory limitations may be an issue with at least Majak.blend. During rendering here, memory requirements peaked at 10.4 gigabytes (this reported by my system monitor). If similar demands occur on your machine, with 16 GB, that leaves less than 5 GB for everything else - operating system and essential applications. I suspect Windows may be detect too much memory contention and is killing Blender. If Windows is stopping Blender, it will log the event. Check your system logs for any such messages. You could also try running Blender from a command line prompt (User Manual Details), where failure messages may be posted by Blender itself. If you have a colleague with a machine that has more memory or processors, try the files on that platform. The aim is to discover if you are just having lack-of-resource issues, or if something more like a rendering bug is an issue. With the material uploaded so far, I cannot make that determination. Sunduk.blend is less demanding of resources. If you are experiencing crashes with this file as well, it may be the better candidate for fault isolation for other-than-resource problems.

Nov 12 2019, 12:07 AM · BF Blender

Nov 11 2019

Garry R. Osgood (grosgood) changed the status of T71459: Can't connect to Blender from a distant machine anymore from Unknown Status to Unknown Status.

I use my laptop to connect remotely to it, and use like apps ... Through steam

Hi Samuel,
Alas, we can't fix the World. The little piece of it that we try to keep in order is (mostly) the source code for Core Blender (the application itself, and some key add-ons), so that it compiles into a binary that some operating system like Windows can start up and connect to the local computer hardware - so that when people use Blender, it behaves in ways that more or less conform to descriptions in user manuals. Yes, people run Blender in virtual containers or use streaming software to project Blender - or other applications like games - to remote systems. These kinds of tools interact with the operating system; applications like Blender are unaware that some other agent is projecting whatever the computer is doing over a network, or that the hardware the operating system thinks it has is actually a container virtualized construct.

Nov 11 2019, 9:19 PM · BF Blender
Garry R. Osgood (grosgood) updated subscribers of T59583: Hair Dynamics: entering particle edit mode with baked cache crashes blender.

Yes. Confirm that assert() with a debug build. The assert has it's heart in the right place. There is nothing actually in the line of baked hair particles to edit in 2.8x. Ideally, in the presence of baked hair dynamics, I shouldn't even have the ParticleEdit mode available to me. It should stay off the menu until such time as the bake has been dropped. (but that is more than a few lines fix). I think in T53780 @ronan ducluzeau (zeauro) raised a good point: neat, geeky trick aside, how useful is it to edit particle key histories? Eh - not sure on that one.

Nov 11 2019, 7:40 PM · Tracker Curfew, Nodes & Physics, BF Blender
Garry R. Osgood (grosgood) added a comment to T71255: 2.82 Particle Hair not showing as expected in Cycles viewport/rendering due to optix rendering.

I trust you've watched How to Report a Bug in 5 Steps - Blender.

Nov 11 2019, 6:48 PM · Cycles, Physics, BF Blender
Garry R. Osgood (grosgood) added a comment to T71460: Hair dynamics don't work with smooth shading.

Looks like T68681. I could not reproduce that bug because I have only AMD cards around here; the issue with T68681 and possibly this incident seems particular to NVIDIA cards.
[Edit]
Just tried it with @Philipp Oeser (lichtwerk) 's test file. Did not reproduce it; animation is correct with both smooth and flat shading. Suspect this is an NVIDIA specific issue; have only AMD cards here.

Nov 11 2019, 5:01 PM · Physics, BF Blender
Garry R. Osgood (grosgood) updated subscribers of T59583: Hair Dynamics: entering particle edit mode with baked cache crashes blender.

@Philipp Oeser (lichtwerk)
TL;DR:
A minor oversight, methinks, but please consider updating rBe02ecd599bdc to cover the possibility of edit->psys being NULL, which can be the case. Perhaps use the standard sanity check common in the immediate vicinity of this code path:

[1597]/* Only do this for emitter particles because drawing PE_FADE_TIME is not respected in 2.8 yet
[1598] * and flagging with PEK_HIDE will prevent selection. This might get restored once this is
[1599] * supported in drawing (but doesn't make much sense for hair anyways). */
[1600] if (edit->psys) {
[1601]   if (edit->psys->part->type == PART_EMITTER) {
[1602]     PE_hide_keys_time(scene, edit, CFRA);
[1603]   }
[1604] }
Nov 11 2019, 2:59 PM · Tracker Curfew, Nodes & Physics, BF Blender

Nov 6 2019

Garry R. Osgood (grosgood) added a comment to T62993: Hair particles: rekeying, cut tool, subdividing do not interpolate existing weights (breaking simulation).

@Lance Phan (ssendam) wrote:

The hair is now completely messed up.

A few notes to somewhat resolve this broadly contoured observation.

Create a hair system on the default cube, set the emission number to 1.

Mine looks like this:


The single hair particle has three keys: one root, one midway key and one tip.
Here is a weight dump of those keys from the python console:

>>> solo = bpy.context.active_object.particle_systems['Solo']
>>> type(solo)
<class 'bpy.types.ParticleSystem'>
>>> for k in solo.particles[0].hair_keys : k.weight 
1.0
0.5
0.0
>>>

This is the visualization of the hair and its keys, using the weight paint tool while in Particle Edit mode. The root has a weight of one, the tip has a weight of zero and the midway key has a weight of one-half.


By the way, the host mesh is a one-face plane. We're peering down the Y+ axis toward the origin, Orthographic projection.
For readers new to the Blender Hair Party, hair key weights engender immobility under Hair Dynamics. Under the root, weight 1.0, is frozen in place. The tip, weight 0.0, is freely affected by gravity and such. The midway key is half-immobile at 0.5.

Go to particle edit mode, subdivide one or 2 segments of the hair.

I'll subdivide the segment between the midway key (weight 0.5: 'green') and the root key (weight 1.0: 'red')


We are in the weeds. Select two keys and subdivide from the right-hand mouse button menu invokes bpy.ops.particle.subdivide() which places a new key nicely between the two selected keys - but weights it at zero.

>>> for k in solo.particles[0].hair_keys: k.weight
... 
1.0
0.0
0.5
0.0
Nov 6 2019, 12:24 AM · Nodes & Physics, BF Blender

Nov 3 2019

Garry R. Osgood (grosgood) added a comment to T71255: 2.82 Particle Hair not showing as expected in Cycles viewport/rendering due to optix rendering.

@Garry R. Osgood (grosgood) wildly and speciously claimed:

Nov 3 2019, 3:30 PM · Cycles, Physics, BF Blender

Nov 1 2019

Garry R. Osgood (grosgood) added a comment to T71255: 2.82 Particle Hair not showing as expected in Cycles viewport/rendering due to optix rendering.

Can partially confirm.

Cycles does not show the hair at all...

Not using a texture as a color source, instead using the color native to the HairBSDF, I find that the hair is wholly desaturated in Cycles, but is present in an F12/viewport render. I did not try a color texture as you did, and did not get a bald head.

Switching to Eevee - they hair shows but only in black...

The Hair BSDF is not compatible with EEVEE. per T56207, hair using this shader will show up as black in EEVEE.

Nov 1 2019, 1:33 PM · Cycles, Physics, BF Blender
Garry R. Osgood (grosgood) added a comment to T71240: Instanced Metaballs don't appear on final render, they do on rendered viewport.

I find the behavior of this blend file the same as that in T69753.

Nov 1 2019, 12:38 AM · BF Blender

Oct 31 2019

Garry R. Osgood (grosgood) added a comment to T69000: Hair: changing children related settings not updating in particle editmode.

@Philipp Oeser (lichtwerk)
For what it is worth, I applied D5912 & D5914 here - no longer seeing the buffer overwrite or total point count / total cache count disagreement. These look like a go. Gave me useful insights as well; thank you for that. Very much appreciate your work in this dusty old particle code. Thank you for that as well.

Oct 31 2019, 11:47 PM · Nodes & Physics, Dependency Graph, BF Blender
Garry R. Osgood (grosgood) added a comment to T71240: Instanced Metaballs don't appear on final render, they do on rendered viewport.

I believe this is another occurrence of T69753. Not in a place where Blender is available at the moment; will check in a few hours when I'm back at the studio.

Oct 31 2019, 7:17 PM · BF Blender

Oct 29 2019

Garry R. Osgood (grosgood) added a comment to T71163: Metaball particle sources jumping around.

Here, I consistently find that AddressSanitizer reports a use of heap memory after it has been freed. Specifically, one thread uses a region of heap that another thread has freed. Details in address_sanitizer_T71163.txt


The failure point is consistently at particle.c:1282 within psys_interpolate_face()

Oct 29 2019, 12:17 PM · BF Blender

Oct 28 2019

Garry R. Osgood (grosgood) added a comment to T71163: Metaball particle sources jumping around.

Sometimes, but not always, Blender will crash

Similar to T69578 in many ways. Not convinced yet, but interested to see if I can produce trace backs for both bug reports.

Oct 28 2019, 7:50 PM · BF Blender
Garry R. Osgood (grosgood) changed the status of T71158: Blender won't launch on archlinux from Unknown Status to Unknown Status.

@Alexa Ognjanovic (GrbavaCigla)
Thank you for the report. The issue appears to reside in packaging the binary for the Archlinux distribution. The Blender team does not generate binaries for specific distributions or distribution systems and has no direct control on how distributors make packages for their communities. I can't speak for ArchLinux, but they appear aware of the problem and appear to plan to rebuild their Blender package. Thank you again for reporting; hopefully we can help you with issues more in our scope in the future!

Oct 28 2019, 5:31 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T71158: Blender won't launch on archlinux.

To me, this is a packaging issue and the good people at ArchLinux appear to be aware of the problem. See their issue report:
[[https://bugs.archlinux.org/task/64287?project=5&string=blender|FS#64287 - [Blender] is not running after upgrading alembic]]
Generally, issues on how Blender gets package for various Linux distributions lives with those distributions. Being upstream, There is not much that Blender development can do about distribution packaging issues.

Oct 28 2019, 5:07 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T69000: Hair: changing children related settings not updating in particle editmode.

@Philipp Oeser (lichtwerk)
Ah me. I can't connect the dot(s) from what I'm seeing to your August 21 musings.
Generally, what I'm seeing is AddressSanitizer catching a heap-buffer-overflow at particle.c:2549 in psys_thread_create_path. Just before falling into the abyss:

Oct 28 2019, 2:28 AM · Nodes & Physics, Dependency Graph, BF Blender

Oct 11 2019

Garry R. Osgood (grosgood) added a comment to T70716: smooth shading doesn't appear work at all in both cycles and EEVEE.

Just thought I'd try moving some of my commercial work over to Blender...

Via Alembic import, perchance? See T70710. See also T69182. Thank you in advance for any clarification!

Oct 11 2019, 3:21 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T69182: Auto-Smooth does not work on Alembic meshes without normals.

Apart from importing via Alembic, there have been issues with smooth/flat object shading regarding NVIDIA cards. See T68681. It is plausible that an Alembic import can be successful, but a manifestation of T68681 disrupts the observation of a flat/smooth object setting.

Oct 11 2019, 2:57 PM · Alembic, Data, Assets & I/O, BF Blender

Oct 10 2019

Garry R. Osgood (grosgood) added a comment to T70702: hair particles not rendering when rendering a tereo image from command line.

Also, T62254. That report makes no distinction between command line and in-application rendering, however.

Oct 10 2019, 3:03 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T70702: hair particles not rendering when rendering a tereo image from command line.

This looks like T70114.

Oct 10 2019, 2:50 PM · BF Blender

Oct 9 2019

Garry R. Osgood (grosgood) added a comment to T70642: Bake All Dynamics not baking hair particles.

When working with multiple particle emitters on a same object, The Bake All Dynamics button doesn't bake anything (when the particles are hair)...

Oct 9 2019, 2:29 PM · Nodes & Physics, BF Blender

Sep 6 2019

Garry R. Osgood (grosgood) added a comment to T62893: bake hair dynamics issues.

@Philipp Oeser (lichtwerk)

... might stem from the issue that these caches sometimes cannot be generated correctly (see reports like T62563: Hair Dynamics: cannot generate a valid particle cache)

This might narrow your search scope. T62563 is grounded in a memory management tactic adopted for the rendering depsgraph, which, since November 2018, is deleted after use on every frame. The need to do that arises from the large memory consumption of the rendering depsgraph contending for the equally large memory requirements of the renderer, observed in some of the fairly immense scenes found in the Spring production. Unfortunately, hair dynamics code examines particle system state across multiple frames, and gets confused when the cleaning up of the rendering depsgraph also cleans up the cow'ed object and related particle system buffers. There are some text files which I wrote attached to that bug report which goes into gory details.
That issue doesn't figure in this bug, I don't think, because the depsgraph for the viewport has an indefinite lifetime; the disappearance of a depsgraph does not drive this bug in the manner that it does for T62563.
Per the User Guide particle editing by and large depends on a pre-existing in-memory baked cache: baking to disk does not support particle editing. The cache also needs to be frame-to-frame coherent. An in-memory cache with dropped or trashed frames can give rise to all kinds of interesting behavior but the issue would be difficult to notice until the particle system loads the queer data and tries to manipulate it. I suspect (but have not proved) the case of corruption after cache generation from time to time, making bugs of this type transient in nature. That's as far as I come with this. Thank you for your work in - at least - bringing some order to the bug reports surrounding the dark secrets of the particle and hair system.

Sep 6 2019, 3:58 PM · Nodes & Physics, BF Blender

Sep 4 2019

Garry R. Osgood (grosgood) added a comment to T69265: Hair Dynamics: not working with non-uniform scaling.

Yes. Sorry about that - the video was a fast load before I was off to my office and I probably screwed it up somehow. It doesn't play here either. Can fix it after I get back to my studio tonight (four hours from now, five allowing for domestic fiddle-faddle...)

Sep 4 2019, 5:36 PM · Nodes & Physics, BF Blender
Garry R. Osgood (grosgood) added a comment to T69265: Hair Dynamics: not working with non-uniform scaling.

@Philipp Oeser (lichtwerk):
I'm a bit slow on the uptake, but I'm trying to figure out what it is I'm supposed to be seeing.
There is a sudden, abrupt transform that happens to the hair itself. Almost looks like a shear. Shot mpv-shot0001.jpg is the frame immediately before the transform, and mpv-shot0002.jpg is immediately after. Other than that, the hair dynamics looks pretty much as intended. See my vid_T69265.mp4. That abrupt transform - that's the manifestation of the issue, right?


Sep 4 2019, 1:36 PM · Nodes & Physics, BF Blender
Garry R. Osgood (grosgood) created T69469: Address Sanitizer reports read overrun in blender/windowmanager/intern/wm_operator_props.c.
Sep 4 2019, 3:00 AM · BF Blender

Aug 20 2019

Garry R. Osgood (grosgood) added a comment to T68681: Hair Dynamics: simulation doesn't work depending on smooth/flat shaded surfaces (and nvidia gpus?).

Thank you for the confirmation and the added information about edit mode effects. I think the object setting of flat/smooth shading is key - and that NVIDIA cards are in place. Those are the two salient aspects of this bug. People without an NVIDIA card cannot observe or confirm this bug.

Aug 20 2019, 3:03 PM · Nodes & Physics, BF Blender

Aug 16 2019

Garry R. Osgood (grosgood) updated subscribers of T68737: Hair fails in Windows 10 and linux Ubuntu.

Smooth/Flat issue similarly reported by @Imre Varga (imrevarga) in T68681.

Aug 16 2019, 5:27 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T68681: Hair Dynamics: simulation doesn't work depending on smooth/flat shaded surfaces (and nvidia gpus?).

Hi Imre,
At first glance, I see nothing unusual in system-info_imrevarga.txt. I need to spend further time with it, but not right now - I'm off to my job and won't be home again until quite late tonight - 22:00 zulu or so.
It seems that when you set mesh smoothing to flat, the simulation runs properly. (Here, linux/amd card, smooth/flat is irrelevant. The simulation runs correctly in both settings).
That suggests a workaround: First, set mesh smoothing to flat, then bake the simulation - in the cache settings, Particle properties, click on the "Bake" button and let the bake run for the full length of the animation. This is similar to what @Philipp Oeser (lichtwerk) proposed (Delete cache, set smooth off, Bake, test animation in the timeline - new step in bold). I propose that this approach will at least give you a sane cache of the simulation to save and work with and you can move forward with your project. If it does, I'd appreciate a confirmation here. Thanks!

Aug 16 2019, 1:35 PM · Nodes & Physics, BF Blender
Garry R. Osgood (grosgood) added a comment to T68681: Hair Dynamics: simulation doesn't work depending on smooth/flat shaded surfaces (and nvidia gpus?).

@Imre Varga (imrevarga)
Similar to @Philipp Oeser (lichtwerk), I can confirm your observations up to, but excluding, your last step:

changing settings, clearing cash ... all to no avail

I do not have that issue here. Changing settings clears cache. Baking sucessfully caches a new simulation that shows none of the issues you report. Particulars:

  1. I temporarily cleared the Dynamic Hair checkbox, which cleared the cache loaded with your file.
  2. Then, probably unnecessarily, ran the animation with Dynamic Hair unchecked, just to satisfy myself that there were zero frames cached in memory.
  3. Finally, I restored the Dynamic Hair checkbox and baked all 100 frames. Blender reported a cache of 100 frames, consuming about 25.2 MB

This gave me a clean animation. See T68681.mkv Compare with the animation made with your original file and its original cached data. See T68681_original_cache.mkv
To make these animations, I modified your file slightly: I put a damped track constraint on the camera so that it would follow the head.

Aug 16 2019, 2:44 AM · Nodes & Physics, BF Blender

Jul 24 2019

Garry R. Osgood (grosgood) added a comment to T67555: Hair collision doesn't work.

I believe there are already representative reports for this condition.

Hair simulation goes goes haywire...

See T59742 and the associated video.

  1. Run simulation

If the means to run the simulation is through Cntl-F12 then the simulation will not run correctly. See T62563.

Jul 24 2019, 3:13 PM · BF Blender

Jul 20 2019

Garry R. Osgood (grosgood) updated subscribers of T67069: Hair particle disconnect and then reconnect results in mess in children hairs.

After spending some time experimenting with this, I am convinced that this report is another manifestation of T54488.
While that report has "mirror modifier" in its title, later work by @omgold (omgold) uncovered broader difficulties with disconnecting/reconnecting hair particles while other modifiers are on the stack, in particular the subdivision modifier, which this poster also included in the stack. See @omgold (omgold) 's commentary there for particulars, along with his emails with @Brecht Van Lommel (brecht). Essentially this is an old 2.7x particle system bug that has carried over to 2.80.
Perhaps there ought to be a "documentation fix" to this and T54488; to wit: avoid (or first apply) modifiers before undertaking hair particle editing sessions, or follow "Noschenko's Rule" and work with "emissions = 0" systems; for reasons that are not entirely clear to me, hair particles originating from particle editing sessions have less difficulty re-finding their root locations after a disconnect/reconnect cycle.

Jul 20 2019, 1:07 AM · Tracker Curfew, Nodes & Physics, BF Blender

Jul 18 2019

Garry R. Osgood (grosgood) added a comment to T67069: Hair particle disconnect and then reconnect results in mess in children hairs.

TL;DR - Guide hairs added through the particle editor only are not affected by disruptive translations, scalings or rotations under disconnect/connect cycles. Hair particles emitted by the particle system itself are affected. Set particle emissions to zero and add guide hair only through the particle editor.

Jul 18 2019, 2:59 AM · Tracker Curfew, Nodes & Physics, BF Blender

Jul 17 2019

Garry R. Osgood (grosgood) added a comment to T67069: Hair particle disconnect and then reconnect results in mess in children hairs.

@Marek Hollý (asil8567)
Took me awhile to get to my desk last night, but I did run your file and confirm both your original report and the unusual rotations/translations which occur to child hair.
I also could reliably crash blender by test rendering (F12) while in particle edit mode. It does seem your file triggers a "certain fragility."

Jul 17 2019, 3:29 PM · Tracker Curfew, Nodes & Physics, BF Blender
Garry R. Osgood (grosgood) added a comment to T67058: Issue in hair particles..

@George Simister (AnaxondA): If you fixed the problem for yourself, then that is great!
If, in the course of fixing the problem yourself, you migrated away from the circumstances that created the bug - and you can't get back to those circumstances easily in a non-destructive way - then c'est la vie...
Bug fixing mainly depends on a file and procedure that reliably recreates a problem. That establishes the all-important anchor point to start an investigation. In the absence of that, it's mostly time-consuming guesswork that leads to little in the way of profitable results.
This bug report will stay around for awhile in a "Need information..." state. If you happen to rediscover the bug, then post the blend file here and a decent, brief, narrative of how you arrived at the circumstances of the bug. Otherwise, this report will be closed at some point because it offers no useful investigative starting point. Thanks for reporting!

Jul 17 2019, 2:40 PM · BF Blender

Jul 16 2019

Garry R. Osgood (grosgood) added a comment to T67069: Hair particle disconnect and then reconnect results in mess in children hairs.

I'm about four hours away from checking this with blender, but this reminds me of T54488. Is there a mirror modifier in play?

Jul 16 2019, 6:11 PM · Tracker Curfew, Nodes & Physics, BF Blender
Garry R. Osgood (grosgood) added a comment to T67058: Issue in hair particles..

How would I upload the .blend file properly?

On the control panel header of the text editor box where you type comments there is a little black cloud icon with a white upward pointing arrow on it - next to the last on the the left hand side.
Click on that; your browser should initiate a file upload session. Click on the browse for file (or some such wording) and navigate to your .blend file and choose it.
You should be good to go.
Thank you for the picture - this helps narrow matters for me.

Jul 16 2019, 3:41 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T67058: Issue in hair particles..

Could use clarification on 6. "Rendered a quick image to find hair behaving sporadic."
Very well, you are seeing something wrong but the phrasing of step 6. doesn't visualize the issue.
A picture is worth a thousand words, and all that.
Better yet, a .blend file with steps to recreate what you are seeing. Could you post one, please? With steps that lead to this "sporadic" behavior? Thank you!
Insofar as particle behavior being set by vertex groups, this reports shares similarities with T63166, but there is not enough information to declare that one is a duplicate of the other.

Jul 16 2019, 3:16 PM · BF Blender

Jul 11 2019

Garry R. Osgood (grosgood) updated subscribers of T66689: Viewport isn't updating Children hair particle on particle edit.

Seen also in T65565 which lead to that "faux" bug report.
Note, in particular, @Clément Foucault (fclem) closing comment on tagging.
A short video clip there illustrates the effect.

Jul 11 2019, 2:21 PM · BF Blender

Jul 4 2019

Garry R. Osgood (grosgood) added a comment to T65565: Hair Particle system not behaving.

The Bspline option does work. There is just a missing tagging, if you click the viewport it works.

@Clément Foucault (fclem) : Yes. That bit me in the posterior regions. I remember going over very carefully relevant parameters and remember looking at Strand Steps, changing it - seeing nothing happen. But, of course, I actually didn't kick the viewport display with a left mouse click. I made a little clip showing that it really does work, as you said - once a deliberate left mouse click was made on the viewport.

fixed_T65565.mkv

So taking everything into account I can't think this is a bug. Or maybe i'm missing something?

You're fine - not missing a thing. On the narrow technical content of this report, you are right: the bug isn't there. I'd vote for closure.
But mouse clicking in the viewport is still a PITA - a UI papercut kind of bug, methinks that's just going to confuse people. Should I open another bug report confined to just that issue?
Thanks for all your great work by the way - you and the rest of the crowd.

Jul 4 2019, 12:40 AM · BF Blender

Jun 28 2019

Garry R. Osgood (grosgood) updated subscribers of T65468: Hiding Portions of the Control Grid of a Nurbs Surface Leads to Incorrectly Drawn Unhidden Mesh, and Artifiacts .

Quick bump here. @Sebastian Parborg (zeddb) @Jacques Lucke (JacquesLucke) confirmed, but this bug was never assigned. Not mission critical, but I'd hate to see this fall through the cracks on post-2.80 work planning. Thanks!

Jun 28 2019, 2:46 PM · BF Blender

Jun 21 2019

Garry R. Osgood (grosgood) added a comment to T65996: metaballs converted to meshes appear to render at an incorrect isosurface.

Ah...!
A total element count change from 4 to 8 is interesting, for if there is now two radiating points where there were just one before, the isosurface would reflect the resulting change in field strength, which, methinks, we are seeing.
Pity I'm in my office and need to do paywork. Be nice to drop a watchpoint on totelem field and find out where it flips.
Thank you for checking.

Jun 21 2019, 3:08 PM · BF Blender
Garry R. Osgood (grosgood) added a comment to T65946: secondary camera size error.

Thank you for the uploaded images.

  1. The first image is an orthographic projection; the remaining ones are perspective. Have you accounted for this?
  2. Blender 2.80 now automatically switches projections when changing views, which some people find convenient, but this feature can jar the unwary.
  3. If you go to user preferences and set projections never to change as you shift view, do you still see the problem?
  4. I apologize that I cannot point out the exact place in preferences to change this setting. I'm in my office and Blender doesn't live here...
Jun 21 2019, 3:00 PM · BF Blender