- User Since
- Mar 27 2015, 2:47 AM (104 w, 5 d)
Sun, Mar 19
For a more up-to-date discussion of this issue, see here:
Yes, that's exactly what I said --
Sat, Mar 18
It turns out that these compiler warnings --
Mon, Mar 13
The two separate compiler errors involved here (neither is actually a Blender issue) are now the subject of two Debian bug reports. Patches are available upstream for both problems, as mentioned above.
It turns out that the "invalid argument type 'X *' to unary expression" compile errors are the result of a known bug in LLVM. It is said to be fixed in LLVM-v5; see here:
This same problem (actually, several problems) has been reported here; it's not distribution- or hardware-specific:
Sun, Mar 12
Adding device specific code for a few specific cases does not abstract that away.
The more code we can share between CPU/CUDA/OpenCL the better, every device specific code we add can get out of sync and makes it more work to maintain, so I rather not do this.
I didn't reuse CL_M_*_F since we need the defines for C++ and CUDA too,
and adding an OpenCL specific variation would not simplify the code.
Fri, Mar 10
It appears that the openCL standard header file <cl_platform.h> already defines
almost all of these constants:
There's a whole header file with this problem:
Mar 27 2015
modifiers do not affect objects, they affect geometries (i.e. object’s data). Since empties have no data/geometry, they cannot have modifiers...
why is there no way that an empty object can be used to control the visibility of its children?
Is there a reason why this should be so? Can recursive application at least be made an option?