- User Since
- Oct 31 2004, 9:29 AM (892 w, 1 d)
Tue, Nov 16
Oct 13 2021
thank you very much for the fix! I already commented in the according issue report! Helps a lot here!
Version blender-3.0.0-alpha+master.53af51ad50ec-linux.x86_64-release.tar.xz no longer crash or hard lock when editing particle hair. Thanks for the fix ! :)
Oct 12 2021
Sorry - my report was partly wrong. The problem with the hard lock when editing particle hair is still there.
But the checksums are still misleading. From my harddisk:
Both were downloaded form builder.blender.org.
The build done at about 2:00 is no longer there.
The later, working build is here:
Oct 9 2021
Jul 26 2021
System/graphics card data were not transferred:
Operating System: Gentoo Linux, updated daily (pure X11, no Wayland)
Graphics card: NVIDIA Corporation TU106 [GeForce RTX 2060 SUPER] (rev a1)
May 23 2021
The building of experimantal builds every night independantly from changes is known to me - that's since the genesis :)
Identical checksum reflects indentical content then - no problem at all.
But under "normal circumstances" (that is without bots being swapping around) I would say it is a little annoying being urged to compare
archives contents by hand when checksums are identical (I mean...indication of differnces is the reason behind the existence of checksums, isn't?)
But if currently 'everything is shifting"...ok, then the checksums are more of an decorative form of mathemitcal art... :) for a shorter period of time, I think.
So no problem for now.
.....and: What are "normal circumstances" in the field of software development anyhow ? :) :)
May 19 2021
Correction: The Video Card is: NVIDIA Corporation TU106 [GeForce RTX 2060 SUPER] (rev a1)
(I copied the wrong line from lspcis output...sorry)
Mar 26 2021
Fix confirmed with: blender-2.93.0-de1eeaa3d24a-linux64:
With an empty scene and nothing selected the list of operators is created with no problems at all.
Mar 25 2021
Mar 20 2021
The clearcoat roughness shows the same effects as described by Evan Wilson for roughness above.
May be this could help to narrow down the piece of code...
Mar 16 2021
Nov 17 2020
After applying scale to the NLA-strip after it has been moved even destroys correct rendering.
In my opinion this should be rated as bug.
Oct 16 2020
Currently it is possible to render negative frames with Eevee only ( https://developer.blender.org/T81534 ).
If an animation created this way and checked subsequently with Eevee for faster turnaround times should
be "ported" to cycles, one has to go through all NLA stripes and for any curve one has to fix the restricted
frame ranges by hand.
Oct 9 2020
Here it comes... :)
Load the file into blender
Select the NLA stripe
Go into tweak mode (<TAB>)
In the graph editor window there is a fcurve displayed.
This fcurve has a nois emodifier which restricted frame range (0...250)
Leave tweak mode
Move the NLA-stripe 250 frames right ( g 205 <return> )
Go tweak mode
Now the fcurve has moved 250 frames to the right, starting 250, ending 500
But the modifier still influences the range of 0...250, which is not exspected.
"Apply Scale" and "Sync Action length" do not change this.
Oct 8 2020
May be an additonal idea:
I use negative frames as a way to initialize a certain setup to start with "the real animation".
And I see no problem in disabling rendering for negative frames at all -- if it is consistence
But I would make it more clear to the user GUI-wise:
I can rendering negative frames when doing as follows:
Select all NLA stripes (includiing those with negative frame counts)
Edit the start frame field by preserving the "-" to a negative frame of your liking
Render Viewport Animation
(using mkv and playing with mpv creates no problems, the frame number display ("i")
also works but count frames starting with 1.)
Rendering with cycles starts with frame 1 and ignores the negative frames though.
Oct 7 2020
No...it was not. I enabled it again and Cycles is there again.
BUT: I didn't disabled it. Is it now disabled by default with 2.91 alpha?
Sep 22 2020
Fix confirmed with blender-2.91.0-8d1123ba220b-linux64.tar.xz. It works again. Thanks a lot! :)
Sep 18 2020
Aug 14 2018
Thanks for the link to CUDA-Z! Very helpful tool.
It is a system wide problem and not blender-related.
I passed this error to the GENTOO developer crew.
This task/ticket can closed.
Aug 13 2018
Sep 18 2016
Sep 17 2016
Sep 11 2016
Yesterday GENTOO-Linux updated to x11-drivers/nvidia-drivers-370.28 also.
Blender works fine now.
A big THANK YOU to the GENTOO-developers to include the new dirver
Aug 20 2016
Hi Brecht, hi YAFU,
Aug 19 2016