- User Since
- Sep 8 2008, 7:02 PM (616 w, 4 d)
Sun, Jun 28
Hi. I'd love it if you guys check out my small proposals about UV editor UI, both garnered some attention on rightclickselect
May 29 2020
May 23 2020
May 8 2020
May 6 2020
Maybe I'm wrong but I think it's based on OpenSubdiv, which in itself is another standard, so pick your poison. But I agree, I think it should come back as an option, particularly if it gives old performance back
May 5 2020
Apr 30 2020
Apr 28 2020
Could another bone, or another bone in another object be used? Then calling it custom would make sense.
Apr 24 2020
Judging by the image of the list collapsed, my first instinct is that it doubles as a menu. In that case I don't think it's too much clicking if you use a click and drag, the advantages and niceness would outweight.
Apr 20 2020
Apr 15 2020
This only solves the cycling, but not what bone is supposed to be selected first for both pose mode and edit mode. If a bone is inside another and your mouse is over the smaller bone inside, the old behavour would be for the smaller bone inside to be selected first. This new behaviour makes it harder in some rigging scenarios where the order of active or selected bones matter.
Apr 11 2020
Wait, so this is a different algorithm than the current unsubdivide function? Then, please, add it as its own command in edit mode and in the decimate modifier where the current Unsubdivide is. It seems to handle more/better cases. The old algorithm is still useful, though, for those mid-unsubdivisions that make diagonal faces.
Apr 10 2020
Apr 4 2020
Mar 29 2020
Comparing it to other aspects of blender isn't fair. Compare it to every other software that does baking and realize that they don't do it to fit a structure of a software, they bake multiple objects and treat them as jobs because it's what's practical. It's what works. Look at any videogame and the level of detail in their texture work. These kinds of workflow demand it. It's best to make it right to begin with or the baking system will be replaced a third time
really cool. for what it's worth you've convinced me. it wouldn't be the first time a feature is "replicated" when in reality they have unique strenghts (displacement mod vs displacement shader, wireframe mod vs wireframe shader, ao shader vs ao passes, hell, even cycles vs eevee) i can already imagine making things with this that aren't strictly cartoon lines.
Mar 24 2020
here's what i found on the wiki about the possible future of simulations.
Mar 21 2020
Any plans for stereo 360? My understanding is that it is not as simple as having two, it involves translation to get correct results, which Cycles handles perfectly. But real time engines like unreal have to make a lot of vertical splices and move the camera on each rotation. Even if not realtime, it would be nice for Eevee
Mar 15 2020
Any progress on this? It would be great to have, I neede this in production a month ago.
Mar 12 2020
Mar 3 2020
Any plans for multiproperties editing for every data type on the Sidebars of all the editors and modes? Nodes, video strips, track points, mask splines and points, Greasepencil layers, Fcurves and keyframes, NLA tracks and strips, plus the modifiers that some of them have, etc
Jan 17 2020
Jan 12 2020
As a way of storing data for animated models, Multires modifier has advantages over displacement textures. With displacement textures, you first have to UV map, you have to bake (which there is no support for baking vector displacement maps currently) you have to make sure the texture resolution is proper, sometimes you get artifacts if the mesh vertices changes or don't align, or other kinds of artifacts due to the model deforming and CatmullClark subdivision, then you have to worry about using the modifier vs using the shader node in case you need to see the detail in the viewport, etc etc. Some of these are fixable by the user by learning new practices but some inevitably make things slower.
Jan 8 2020
Dec 11 2019
Nov 19 2019
I can confirm as well, I went through the original Intel documentation and was surprised at how good results they have on their page, and the claim that Denoising Albedo is the best input for the denoiser to have. The current denoiser albedo pass is simply adding the Glossy Color pass to all the others Color passes, but the Glossy Color pass doesn't contain percentage of reflectivity for things with frenel. The intel documentation doesn't specify a correct solution though, it's up to you what passes you choose and what combination, for example, if you want to add reflections to the mix or not, and how to do it, taking just the color or the actual first bounce. My current setup is to add Diffuse Color, SSS color and Translucent color, leaving Glossy color out.
Nov 5 2019
In other software and Blender addons that have tried to tackle this, they use a design called Jobs. In these jobs you specify the passes and objects (could be a collection) that should be baked, to which UV map, as well as cage relationship. Then you may bake one or all jobs. The less you have to set up per object and per material, the better. Then it's up to the user if they need a special case of individual bakes per material or per object. You don't have to design a UI where you select one UV map for each object either, instead, in the Job you select just one UV map index or name, and it's up to the user to make sure the objects don't overlap in UV space, they can always create more jobs.
Nov 2 2019
Oct 29 2019
Not related to this task, but having search on the Preferences would be great too
Sweet! I hope these proposals are considered
Oct 26 2019
Sep 19 2019
My understanding is the same. It's used to blur face corner colors into all the adjacent corners, but it doesn't actually blur like in Weight paint or with the blur brush.
Sep 11 2019
Sep 1 2019
Aug 18 2019
Nice! Unrelated but, shouldn't displacement affect both the specular and clearcoat layer? Technically displacement is a stand in for real geometry displacement so it would affect both, which is what Cycles does btw, unlike Bump to Principled where each reflection has it's own normals for good reasons.
Aug 11 2019
It's not as before. Pressing A once always selects, and pressing Alt+A deselects. You can also double tap A to deselect but it has to be fast. If you want to use the old behaviour from 2.79, go to Preferences, keymap, and click on Select All toggles
Aug 9 2019
Aug 8 2019
Aug 4 2019
It's not per image file but per image datablock, you can have two image datablocks that have the same image file as pointer, but different color spaces. Just click the little number besides the datablock and this will duplicate it.
Aug 1 2019
Then maybe we don't want those tools at all, or speaking for myself, I don't. They sound so specific that they're more fit to be part of an addon than anything else.
Jul 14 2019
Any updates on this?
Considering that I model a lot and haven't encountered the problem again, even when I try to replicate my own instructions, I say this has been solved
Color management isn't applied until you save the image and it's not applied on EXR. You could've saved it as EXR, and applied the color management to that image later, to not have to re-render again
Jul 13 2019
I can't replicate it on blender-2.80-e3c586e262dd-win64. Eevee and Cycles values look the same for me, and color management works as well.
Jun 28 2019
Jun 26 2019
Contact shadows are screen space. They have the typical limitations of the other screen space things like AO and reflections. The thickness of the wall behind doesn't exist as far as screen space is concerned. I barely use them because of that and other limitations with thin object.
Jun 16 2019
May 29 2019
May 28 2019
May 25 2019
I can replicate it in the sense that they happened to me in some frames of an animation but I couldn't pinpoint what angles point of view caused it. All that I can confirm is that they happened with AO+Bent normal + Subsurface. It was force to fix this using the Compositor to clamp the high values, erase the alpha and use the Inpaint filter.
May 19 2019
May 17 2019
May 15 2019
Now that rBec0eeb918bac is implemented, objects with a modifier stack deform the textures correctly. All that's left is for objects with no modifier stack to work as well, those being deformed by shapekeys, which I think is the only non-modifier way of deforming meshes that's not being taken into account. Putting a disabled dummy modifier is my current workaround though
May 12 2019
May 7 2019
May 2 2019
Apr 26 2019
Apr 16 2019
Not quite sure if I don't understand the controls or what's happening but I feel it's doing the exact opposite of what I want. It's sampling with max samples the already less noisy bright areas and using even less samples for the noisy dark ones. I'm trying to make the bright areas as noisy as the dark ones, and for the dark ones to remain the same as the base render without adaptative. Maybe it's the build I'm using, idk https://www.dropbox.com/s/s655x863joidbuu/adaptive-sampling.zip?dl=0
Apr 15 2019
Apr 10 2019
Thank you guys!
I agree. Even without an image I make annotations on the positions of UV islands, which needs canvas lock. So the idea of the warning is not ideal either, Annotations definitely have use without an Image open.
Apr 9 2019
What seems to be truly happening is this;
Apr 8 2019
Apr 7 2019
The cross is just caused by a highlight with the Glare node. Either clamp that area of the render or adjust your glare nodes or use other nodes.
Every video editing software allows you to drag and drop entire image sequences at once and form a video strip
Apr 1 2019
Mar 29 2019
I too rely on viewport visibility for my rigs. Allowing me to use drivers to control from within the Armature things like outfits, hiding, showing different object parts
Mar 24 2019
Mar 17 2019
Line segments and Curve segments don't support Subsurface scattering while Triangles does.
Mar 15 2019
You have different Subdivision count in render vs viewport. Set the same subdivisions for both render and viewport and they will look the same.
Mar 14 2019
It was that all along? You guys are lifesavers! ❤
Mar 11 2019
Mar 10 2019
Thank you for the file. After seeing your model now I can definitely find it on mine, but to a lesser extent. It seems those flipped normal are areas where the combined normals go above 90 degrees away from the camera. I imported the model to unreal and it definitely happens there too, but less glossy, more similar to the rest of the material. It would be nice for Blender to do it that way but I'm not sure the developers would consider that a bug instead of a known Eevee limitation.
I can't replicate it with my own models and normal maps, some of which are directX, but all of them look perfect. That's why we need an example blend file with textures attached, to discard factors like the gamma and the kind of normal texture itself, the UV map used as tangent in the Normal map node for model with multiple UV maps, to help you if it's not a bug but just the setup, and ultimately to know if it's just a bug on that happens with one particular gpu driver or a more general bug.
Please provide a blend file with an example of the bug. The nodes are collapsed in that screenshot so it's hard to guess the settings of the math node and the normal map node
Mar 7 2019
The default shadow settings are more on the side of speed than precision. Use ESM shadows with more exponent or use VSM shadows with high bitdepth and 0 bias, make sure walls are thick (double sided), and adjust the Clip Start of the shadows. You should not get any light leaks with this.
Mar 5 2019
Feb 28 2019
Feb 22 2019
I love this! A couple of thoughts:
Feb 20 2019
The noise is smaller than the size of a pixel in the cubemap, and thus the small noise disappears in the downscale process while the few ones that appear look big because that's how big the pixels are. It's like downsampling a picture of stars in photoshop, that's what happens, and no filtering algorithm would solve that 100%. It's definitely NOT procedural textures changing scale, because then it would change scale even with big textures like in the imaged I used above
What you see is a combination of a moire effect, due to small scale of the texture and the low cubemap resolution. Another way of putting it, the texture is so small than when it's captured on the cubemap filtered at a lower res, it just happens to look like a large scale version of the same texture, an optical illusion. But if you use any other procedural texture, or the texture at a larger size, you see that lowres cubemaps don't change their scale. Like in this image with the lowest cubemap resolution possible.