- User Since
- Nov 30 2008, 9:31 PM (575 w, 13 h)
- Added glossy passes as a test. It still needs more work as most nodes haven't been converted yet.
This report does not contain all the requested information, which is required for us to investigate the issue.
It happens after linking the Normal map to the shader tree.
Seems to be failing during generation of the material GLSL.
Sat, Dec 7
Fri, Dec 6
Initial start to have a drawing pass per active renderpass. This is a first step to support material renderpasses for final image rendering
Basic support for:
Thanks for the report!
Small changes before merging to master
Thu, Dec 5
The viewport and the movie clip editor should display the selection of the markers in the same way. Fixing the crash shows that the selection drawing isn't handled the same.
Renamed premul to premult as premult is the coding convention in the draw module
Handled comments from code review:
Set the alpha of the background image to 0.0 and you see that it has the same result as shown in the image above.
there are two things happening.
The images are rendered with no framebuffer attached. So the alpha under blending does not happen, the render. White color is blending in from the color uniform.
Thanks I had a similar solution.
Wed, Dec 4
Is mine commit. Will look at it! Thanks for reporting.
true -> false
I checked and this is also failing for 280, 281 and 282. Seems like a missing NULL check in the selection code.
Seems like incorrect alpha blending.
It seems that the GPU shader is not different. and just reads from the in variable.
AMD has found an issue inside cycles. It seems that some data isn't initialized. Solution would be to clear the memory up front or always initialize all the data we pass to the kernel. The specific data is the object_motion field in __constant KernelData *data. I will try to confirm their findings and make a possible fix.
Seems to be an regression where when the color management happens on the GPU the meta data isn't added.
@Clément Foucault (fclem) During this fix it came to my attention that ArmatureDrawContext.do_relations is never set and unclear what the difference is between show_relations and do_relations. I assume that the do_relations was meant for the mode it is in
Use the do_relations attribute
Tue, Dec 3
Excellent. When running with the gpu scripts. All available workarounds for driver bugs are enabled. One of them needs to be enabled for your driver configuration.
This is a known limitation of the current implementation. It tries to render images for 0.25 seconds and stops so it won freeze the system. On the other hand this will enable to use huge images that aren't able to load on a GPU.
An artist can help you optimize a scene so it can fit on your GPU and you will be able to render your scene. For example he or she can explain to you how Simplify Scene works, or that having many subdivision levels is totally not needed. No developer is needed there. You don't need a developer for that.
This is not a support channel. Please visit blender artists, stack exchange or blender chat for getting support on user questions.
Still some regressions.
[WIP] add a lines_loose ibo
cleared the ibo.lines when requesting the loose_edges batch
better be safe than sorry. will accept the patch.
Personally I find the !defined confusing to read. but cannot find a good solution.
what about adding !OS_MAC to the first if.
Ok, issue seems to be that ibo.lines is filled so isn't requested. As it isn't requested the ibo contains all lines.
my solution would be to add a separate ibo.loose_lines that will be constructed of the existing ibo.lines.
@fulvio bosco (fufletch): Could you attach the blend file so we can do identical checks as you do in the video?
The last change to the GhostWGL part was done in Mai 2019 so would already be present in 2.80.
Looking at the information of the log files. There is a log where it crashes inside the NVIDIA driver, but Blender thinks it is using the Intel GPU. that could be related to the soft switch etc.
My guess would be that a different OpenGL driver is selected between the OS vs Blender. The driver doesn't know the Intel GPU and fails on all calls. But this is a big guess, we need to find proof of this. Especially as 2.80 worked.