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.

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.

I cannot reproduce after rBed96c59c20fb so I will close as resolved.

In T71234#1030363, @M Z (lemi) wrote:

Though, custom property is animated indeed, it is still bugged.
All object animations get cancelled out when overwriting data.body.

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.

In T71234#1031097, @Philipp Oeser (lichtwerk) wrote:

However, there seems to be a "one-frame-off" issue if you take a look at this file:

textcounter-bug-MWE_corrected_animated.blend722 KBDownload

(frames one and two draw the body in the same place, even though its origin already moved -- this could be due to using frame_changed_post though)

In 2.91, it also doesnt seem necessary to read Custom Properties from the evaluated object anymore? (see the following file)
And to fix the "one-frame-off", you can actually use frame_changed_pre in 2.91 without issues:

textcounter-bug-MWE_frame_change_pre_animated.blend723 KBDownload

OK, checked this again.

Could someone please check this out?

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.

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.

Poke. Guys, it is important! It spoils animation direct renders.

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.

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

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.

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

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.

Just tried again with the latest Nvidia Driver:

This is mostly a basic review of Python code.

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.

Hello. Importer & exporter glTF is now using the new socket ( see feca8c528979 and f3cf3a16e989 )

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.