- User Since
- Jan 3 2003, 6:23 PM (746 w, 3 d)
I'd say go ahead, we can always change directory layout later.
Sun, Apr 23
Looks good to me, thanks!
Solver by rB20c9c1b44e13: OSX: satisfy macro to also apply alembic tests before I could review this..
Looks generally fine, mostly minor comments.
Only quite superficially reviewed, but looks ok to commit.
Sat, Apr 22
No reply for a week, closing unless more information is provided.
X Mirror seems to be working fine here. I think this is more a user support question for blender.stackexchange.com or blenderartists.org. X Mirror requires a mesh to be symmetric over the X axis, probably it's not exactly in your case.
@Campbell Barton (campbellbarton), the issue is that blend_m4_m4m4 assumes there is no shearing in the matrix, only scaling. Switching to interp_m4_m4m4 solves the problem but relies on Eigen, which means it can't work with MATH_STANDALONE.
Closing due to lack of information, we can reopen if enough to redo the issue is provided.
I don't know if works anywhere, just that all the OSes tested use the same xorg-server code. In the implemention of XIWarpPointer we find this comment, indicating Xinerama multi monitor support is missing.
/* FIXME: panoramix stuff is missing, look at ProcWarpPointer */
Much better, thanks!
The libxi/xorg implementation is the same on all those operating systems. We'll have to see if there is actually a bug there, it's just something we have to consider given how simple change the from XWarpPointer to XIWarpPointer is and the fact that this is a rarely used function which will not have been tested much.
Looks good to me then.
I don't have multiple monitors to test this, but some notes.
Fri, Apr 21
Thu, Apr 20
It's not committed to master, rather master was merged into this branch.
This seems to be working well in my testing.
Tue, Apr 18
I didn't get direct confirmation but also no further complaints. It would help if you could test 10.9 at some point.
I think it would be good to rebase/squash everything together into one commit. No need to go through patches for that though, the easiest way to do that is to merge the branch into master like this:
git checkout master git merge --squash cycles_disney_brdf git commit
Sun, Apr 16
Perhaps the best solution here would not be to change anything in Blender, but to fix OpenEXR to only apply lossy compression to the Y channel when it is the only channel or if it goes along with BY and RY channels.
Blender uses the default compression level of 45.
Thanks for the report, but this is just a missing feature at this point, one of the reasons this feature is still marked as experimental.
I agree there is a bug here, renamed the title to reflect that. I don't think we need manual control, just for some passes with vector/ID/.. types instead of color we need to tell OpenEXR not to apply lossy compression.
Sat, Apr 15
Here's a simpler fix, to still execute the full mix node but avoid evaluating the other inputs. Any objections to doing this instead?
This sounds almost definitely like a driver installation issue, if other software is having similar issues it's unlikely this is something we can fix in Blender.
The busy cursor appears when any program is not drawing or reacting to user input, and this script blocks Blender execution. The solution would be to avoid blocking the rest of Blender, by for example running tasks in a separate thread or using a modal operator.
The issue is that the Strength needs to be set that high to compensate for the Attenuation being broken. After the fix it should be possible to get good results by only adjusting the Distance.
Fri, Apr 14
So assuming Alembic has no concept of hair attached to a surface, I think that means:
- The curves are already baked onto a deformed, subdivided and displaced surface. Maybe pushed a little into the surface to be sure it's connected.
- UVs and other data are attributes on the curves, which ideally would be imported as curves custom data (which we do not support currently).
Ok, looks good to me then.
@Stefan Werner (swerner), not sure if you already discussed this further with other Cycles devs, but I guess talk to Lukas about taking over this patch if it's important to you?
Great, looks good to me now. I confirmed the random values in Cycles stayed the same.
Fix looks good to me.
Looks good to me, patch seems to working as expected.
I meant intern/cycles/math/, containing both the type and math files, but it would indeed be a more intrusive change. Personally I prefer a flatter hierarchy, but don't mind conforming to the majority opinion if it's different.
Agreed, the fewer modes and states we need to keep track of the better.
Looks good to me. I think a top level math/ folder would be good, to contain these types and other math functions, regardless if we make the private/public distinction.
Thu, Apr 13
@Pascal Schön (VanCantus), do you have time to commit this to master and handle possible bug reports?
Wed, Apr 12
Note that pressing the RenderLayer button in the 3D view header gives results closer to what you get in a final render in the active render layer, including render visibility. In the Blender 2.8 design this can hopefully be solved better though.
Mon, Apr 10
We don't have an unsigned int type in RNA, but exposing it as an int should be fine. In practice casting unsigned int -> int -> unsigned int is a no-op.
Sun, Apr 9
The panels weren't showing up for me when applying the patch, probably due to recent changes from rB9bdda427e6ff. They needed to be added to the classes list at the bottom of the file.
Correct, this is a known limitation. It's possible to do things like get the ID value for the closest object, but that's still almost equally useless in practice.
Nice, this is a feature I've always wantend, as evidenced by the optimistic persistent_data property name. Also for future network rendering this should be nice, where scene export can more easily become the bottleneck even for final frames.
Looks generally fine to me, always nice to have more complete GLSL support.
Why aren't the filters kernels in kernel/? All this duplicated code in CMakeLists.txt, filter_compat_*.h, kernel_config.h is going to make it harder to maintain things.
What is the reason for moving N from the specific BSDFs to all of them? Hair and transparent do not have a valid normal, and since they are not really meaningful in those cases it seems better not to have them at all, so that they can't be used accidentally.
Sat, Apr 8
No problem, thanks for testing. Still kind of interesting that the 32 bit build is so much slower.
The system info indicates you are using a 32 bit version (i686) though, so I think you might have downloaded the wrong build from builder.blender.org?
Factory settings doesn't affect CPU device capabilities as far as I know.
Wed, Apr 5
Tue, Apr 4
Looks good to commit.
Mon, Apr 3
Great find, looks good to me.
Sat, Apr 1
Neither the old nor the new code worked correctly on high DPI displays, fixed now.
Fri, Mar 31
The last patch worked with OpenCL and CUDA for me. I didn't try updating it to latest master, but I don't foresee a problem there.
Thu, Mar 30
Cycles works in a linear color space for physically based rendering, while Photoshop works in different color spaces like sRGB. See here for some info:
Multiplying doesn't seem all that useful to me, for typical 0..1 textures it will just make the subsurface part darker than the diffuse part, for which there is no good justification I think. Controlling the result of two textures multiplied together also isn't very intuitive. A case could be made for having just a base color and no subsurface color at all, but having the separate subsurface color there is useful too. Since we're trying to match an existing standard we might as well follow it here and use blending.
Wed, Mar 29
See T50650, there is a bug in the automatic Windows update of NVidia drivers. Uninstalling and reinstalling drivers manually should solve the problem.
There can be only one object ID per pixel, so when objects are partially transparent it's unclear if it should use the object in front, behind, or the background. The Passes tab contains an Alpha Threshold to control this, which is set to 0.5 by default.
Mon, Mar 27
I've pushed a bunch of changes to the rBuv_unwrapping_slim_algorithm branch:
- Code refactoring to match code style
- Transfer weights in construction, fix subsurf weights.
- Avoid using scene toolsettings, this was old mechanism from before 2.5x.
- Move SLIM integration behind into param_* API, reuse more LSCM code.
- Fix issue with live unwrap and multiple pinned/non-pinned charts.
Mar 25 2017
@Luca Rood (LucaRood), here is fine, I committed a possible fix now in rB393efccb19e4: Fix GHOST crash on X11 with recent DPI changes on some systems..