For UV sphere I would suggest equirectangular mapping
For ico sphere I think can use this coordinate system:
This sounds like a good idea to me.
I hope that external renderers will also be able to use this new editor, to display statistics as well as warning/error messages that happened during the export process (e.g. missing imagemaps).
Seems that I've been confusing by the process, could you make some doc on this feature, please.
For UV sphere, I think should use this coordinate pattern:
I'm giving this task a go together with the T47488
Oh great! Thank you!
Hi @Yegor (Yegor), already have a fix for this, just double checking a few things, so no need to try reproducing any more.
Well, this is embarrassing. I can not reproduce this behaviour anymore on a new object or in a new file. But this file still has the issue, and it's something with this exact object. If you create another one and link the same material it renders fine, but if you copy the broken one, or copy the mesh and separate it into another object it will have the issue still.
Ah yes indeed, looks like there’s a missing usercount handling here… will check.
Hi, first time here. I'm assuming no one is working on this anymore? I'm giving this a shot :). Will also look into fixing default unwrap for the UV sphere. Someone on IRC mentioned it "looks like a truck ran over it" and suggested I start there. I didn't see a tasks for this though.
Sounds good! I will get together a test file that demonstrates some of the real use cases that we've been going through :)
Hi, I'm new here and trying to become a useful (hopefully longterm) contributor to Blender. This sounds like an awful task to start out on but at the same time matrix math is super up my alley. Any suggestions on how I might be useful here?
Updated the patch.
Yet another version, hopefully addresses all the feedback
@YAFU (YAFU), sorry for the spam but forgot to mention.. There will be certain extent of brighter-looking areas in the shadow due to indirect light bounces from the bumps.
@YAFU (YAFU), yeah, apparently previous approach worked fine-ish with BPT as well. Since it was somewhat simpler i'll try rolling back to it but making it to work the same for PR and BPT. That should also fix the issue you're reported about displacement.
Well, the message is pretty clear: you need a GPU driver that supports at least OpenGL 2.1.
Ok, so first of all please open a new bug report since it is something up to do with crash, not with the cuCtxSynchronize. And then:
Fixed by setting TIMEOUT=connect 5s, client 5m, server 10m in the HAProxy docker environment variables.
Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that).
Please do not create design/todo tasks, they are reserved to developers.
Please do not set priority of tasks yourself, especially not to high priorities!
I can attempt a driver roll back and test again. T49113 describes a Linux driver that causes crash on F12. The behavior here is on Windows 10 and crashes part way through the render.
Let me know if there are instructions for generating more detailed Blender crash details.
Let's copy those to GCS instead.
This is then most likely the same error as reported with another 370 series driver in there T49113. As you mention, the driver was released prior the bug report was fired to NVidia so it can't have discovered bug fixed.
Driver Version 372.54 - WHQL
Driver Release Date Mon Aug 15, 2016
The GP-related points are wrong, those are translated (checked with latest French translations), you probably just missed them in-between in Italian (since those messages were cleaned-up/updated in past weeks).
Crash was caused by an invalid cache file pointer in the transform cache constraint added to the empties. The pointer is invalid because it can't locate the alembic archive on disk (which is missing from, not attached to, the report). Anyway, it should be fixed now, thanks for the report!