Blender rendering pipeline.
I can confirm the slowness when rendering Cycles when the maximum texture size is limited (in the Viewport preferences).
I was unable to notice "artifacts" in the rendering result with Eevee, but in fact the final size of the texture is reduced, which was not the case in blender 2.90.1.
Oops, I misunderstood the problem.
I can confirm that it is different.
And in fact the behavior in the render and viewport should be consistent.
Tue, Oct 20
Fri, Oct 16
This seems to be fixed now in (the upcoming 2.91) since (4212b6528afb0) - image draw refactor. Closing it now, let me know if the issue is still around.
Tue, Oct 13
I cannot reproduce after rBed96c59c20fb so I will close as resolved.
Mon, Oct 12
Fri, Oct 9
Both files (frame_changed_post and frame_changed_pre) work in Blender 2.91.0 alpha. I also tested the plugin and it works in Blender 2.91.0 alpha.
OK, checked this again.
Could someone please check this out?
Thu, Oct 8
I agree it's quite weird to tie the visibility to the camera selection, since the border works in the viewport you might not even care about the camera at that point.
Well, in order to see the controls, you need to select the Camera (same as the the scene Camera).
[check in code is a bit weak, so if there is no camera as well as no active object, both are the some (NULL) and you will also see the controls]
Though, custom property is animated indeed, it is still bugged.
All object animations get cancelled out when overwriting data.body.
Look at the file and compare 3d view with rendered animation.
hmm, i've just noticed something else. The first time this file crashed, even though auto save was set to every 2 mins, there was no auto saves for around about 1 hour prior to the crash. So possibly it's auto save related?
OK scrap that. I've just sat and watched it closely to see at what stage it crashes. It saves files fine, then it crashes halfway through rendering the first view layer of the next frame. So it's nothing to do with denoising or file saving.
I think it might be something to do with the file saving, because in my scene I have a file output node in the compositor which is writing a multilayer exr (only 3 layers), and the main output settings are writing out a jpg sequence. I just tried changing the jpg sequence to a ffmpeg video, and it was able to make it to 146 out of 300 frames, whereas when it was set to jpg sequence it was crashing every time within the first 50 frames.
This time it created a log. I've tried running today's daily build at factory defaults and the same issue is happening. Tried to render this animation 5 times now and it's crashing each time. Maybe this should be escalated? Seems quite severe not being able to render animations.
anyone looking at this? Blender hard crashing with no log during animations again today.
Wed, Oct 7
Poke. Guys, it is important! It spoils animation direct renders.
Tue, Oct 6
Mon, Oct 5
Sat, Oct 3
Fri, Oct 2
Yeah, it's such a non-issue and edge case that it really wasn't even worth reporting. lol But I already had the report written, so I figured I might as well let the devs decide if it's worth fixing.
Thu, Oct 1
I guess I will confirm this, though not all codecs do support all options - see https://docs.blender.org/manual/en/latest/files/media/video_formats.html
Wed, Sep 30
Can confirm, Crash occured on frame 3, not sure if this is random though,
Been dragging for the past few days but it feels like the "Faster Obj Import/Export" is coming along quite well. This project would require me to rewrite this patch in C, I am open to doing that. I will finish up the work I have done on this in the next week and consider this a prototype.
Mon, Sep 28
Thanks for update.
With deeper investigation it seems that subsurface scattering is another pitfall. It is a little ambiguous what the PBR extension means when it refers to "Tr" as "translucency". So I took it upon myself to put out a well defined subsurface scattering extension that plays well with all software regardless of feature support rather than relying on a hack. This will be a much better solution for compatibility while not dropping support for subsurface scattering. https://astrand130.github.io/astrand130-github.io/obj-mtl/mtl-subsurface.html
Sat, Sep 26
Just checked and I was able to render all the way through with the OIDN comp nodes muted.
Hi @michael campbell (3di), thanks for the report. I am looking to see if this is tied into some other recent reports, which is the reason for the note below.
Fri, Sep 25
Just tried again with the latest Nvidia Driver:
Sep 24 2020
This is mostly a basic review of Python code.
Sep 23 2020
It appears modern versions of Maya don't have this issue with ambient/diffuse being swapped anymore. I am going to add compatibility code to handle this on import for older files which may be affected. I would encourage users to report bugs to software that still has this issue: it's a them problem, not a blender problem.
Sep 22 2020
Looks like this is just running out of memory? Do we need 10 subd levels on the donut ;) ? Is this how Andrew Price does it?
This would result in 557.466.752 triangles afaict, something a usual computer does not handle well.