- User Since
- May 21 2007, 1:02 PM (685 w, 1 d)
Jun 1 2020
Yeah I noticed this too with GafferCycles, didn't end up sending a patch in I think I just did a workaround, this is better.
Feb 18 2020
- OSL support for AOV output, currently I am seeing the shader isn't compiling under OSL while debugging like it is in SVM.
Feb 9 2020
Feb 7 2020
Jan 20 2020
Jan 19 2020
Jan 14 2020
Jan 13 2020
Jan 10 2020
Dec 26 2019
I just had another thought/idea which isn't necessarily UDIM-related but it might be a good feature to have. In the other renderer backends you are allowed to set the pink missing texture to a color plug. This works well as a fallback, so often in lookdev we would assign a safe texture fallback to the missing texture plug or set it to black if we don't care (like if the model/texture is WIP) or if there's an asset variant change and only some UDIMs are modified and the missing ones would just sample from the base UDIMs via the fallback plug.
I just did a clean build off of Blender master to my standalone Cycles and I can't recreate the issue now, it is pink so that's good. I am balancing the texture cache, openvdb, adaptive sampling & light-groups patch here which probably one of them introduced something weird with the udim patch which I'll try to investigate on my side (gut-feeling it was the openvdb one).
Testing this out on my end. In GafferCycles if I create an image_texture node but have the filename path blank, I will get an assert. My workaround is:
Dec 24 2019
I can also see the potential building-blocks for robust light blockers as well here, great job @Charlie Jolly (charlie) !
Dec 19 2019
If it helps @Juan Gea (juang3d), I was able to compile adaptive sampling support on the fairly latest patches of Cycles here:
Dec 11 2019
Nov 26 2019
Not sure if it might be related, but I reverted the virtual destructors for anything inheriting from ImageSlotTextureNode so that only ImageTextureNode has the new UDIM destructor update. I found that textures like environment maps weren't freeing properly which might be what you're running into, although it was asserting for me but I am building in debug mode and haven't tried a release build yet.
Nov 23 2019
Just a follow-up on a potential fix:
Nov 22 2019
Hey @Lukas Stockner (lukasstockner97) fantastic patch!
Nov 15 2019
Just giving your patch a go for GafferCycles. I might've made a mistake on my end, but I am getting an assert in the ImageManager::remove_image(int flat_slot) function on the EnvironmentTextureNode, when it tries to get the image back from the slot number it returns a null pointer to image. I'll investigate further, but it looks like it is related to removing the destructors and relying on the ImageSlotNode destructor with this patch.
Sep 25 2019
+1 for this. Currently my GafferCycles implementation needs all elements to be persistent by default, and I currently get around this by managing the scene object vectors outside of ccl::scene and making sure to clear the pointers out of Cycles and transplant them back in eg.
Aug 26 2019
Aug 9 2019
Aug 8 2019
I had this posted a day or two ago but I didn't understand how phabricator's differential works. I've made a basic inline comment in bvh_embree.h in which the new function needs fixing to compile properly:
Aug 7 2019
Apr 23 2019
I'm taking a look at this patch to test with GafferCycles but just the Cycles part, but I am seeing if I can merge it with the ImageTextureNode. From what I understand currently, to fill up the tiles you are relying on Blender to fill this up? The approach I am testing is to just let the user pass a filename with the format 'file.<udim>.tx' and then deriving the name at the SVMCompile/OSLCompile stage. Does anyone have an opinion on this? Also should there be an additional projection called 'udim' or 'mari' which works like the standard 'flat' only it explicitly tells the code to treat it as a udim mapping?
Apr 21 2019
Jan 5 2019
Sep 9 2018
Sep 3 2018
Just an update, I managed to build the latest Blender 2.80 here (I had /usr/bin/c++ & cc set to clang not gcc, doh!)
Sep 1 2018
Apr 14 2016
Something which would be great would be a procedural API in the same vein as Renderman and Arnold, where one can dynamically load geometry to the renderer when the renderer hits a bounding box ray hit for the first time.