Yeah babe, see when you use as i use it doesnt work as it suposed too. Simple as that, i have been collecting screens of people complaing about the money and time they are losing for the controversials and unregular changes and arbitrary happening. BLENDER IS ONLY USED I THE ANIME INDUSTRY, th emanagement doesnt care if keeps breaking anime, motion graphics, displacement worflows.
Isnt blender a community project, i have been using for 15 years, i have seen it all happening here in terms of project and waste of time.
I use Blender to make art, help me make art, just that. I know for ego reasons blender never backs itself so CREATE A NEW CATEGORY CALLED
HEIGHT MAPS
PUT MUSGRAVE IN IT, PUT STUCCI INT, MARBLE, PUT ALL THE AVAIABLE NOISE FORMULAS AVAIABLE AT THE SHADER MATERIAL.
If theres not enough complain about this IS BECAUSE PEOPLE ARE STUCK IN 3.5
Some addons cant keep up api changes every 3 months, Abnormal addon is one, so the anime people is stuck in 3.5
Wait until it updates and anime people jumps in 4.1ā¦
Im a super annoying person even more if im dueling with just a symptom of fear of changing the changes, hehe. The noise is good for whomever uses it, but is not the same thing to work with even more with displacement, as proved in the first print screen.
Rafael, with respect - your postings on this is a train of thought that is almost impossible to follow. It just reads like a general, extended rant of ā¦ something.
My work is completely NPR (āanimeā style, if you like), and even with that - these 4 images youāre posting are incredibly abstract; personally I have no idea what your goal is for any of that to look like, compared to what it DOES look like.
The screenshot of your interface clearly shows a node as non-functional, so is a failure of the desired outcome of the new noise node. If you believe this is a bug (and given the daily build, quite likely because things go wrong unexpectedly), then please of course report it with clear, easy instructions how to reproduce it (and attach a file, also helps.)
Just testing stuff here based on @Rafael feedback and I found thereās indeed a difference with displacement. Mind that I wasnāt trying to replicate Rafaelās results exactly, just testing something similar to his setup.
Blender 4.1 converts the Musgrave node to a Noise node correctly, and the black and white output looks exactly the same, but the result is clearly different if using Vector Displacement or Displacement nodes. I wonder if the difference is in the displacement nodesā¦?
HereĀ“s the test file if anyone want to test: MusgraveTest_2.blend - Google Drive
@Rafael The Musgrave node in your shader setup has become non-functional after the conversion to 4.1. However I couldnāt replicate this issue and there also havenāt been any bug reports on that.
Please provide the .blend file that isnāt working so that we can investigate this issue.
@JulianPerez There has been some work done on both EEVEE and Cycles displacement lately. If the Musgrave output in 4.0.1 and the Noise Texture in 4.1 have the same output without displacement itās likely that the problem is caused by some changes regarding the Vector Displacement and Displacement nodes.
I suggest you open a bug report on that. Do these differences in displacement also occur when using it with other types of input (Voronoi Texture, Magic Texture, Image Texture etc.)?
If an artist doesnāt know how to build a node chain of Roughness = power(Lacunarity, -Dimension) the he likely isnāt using the Noise Texture with a mathematical mindset in the first place, but is rather tweaking the input until he intuitively gets the results he wants.
In that case itās better to just get used to the new Roughness input as it does everything the old Dimension does but with more intuitive controls.
The reason I decided to keep the Roughness input instead of the Dimension input is exactly to discourage artists from using it.
The formula is only meant for mathematically minded users who want to achieve a certain mathematical result.
Thatās ridiculous, suggesting that vector displacement could be the cause of different behavior is nonsense. If you put two identical vectors into vector displacement, you get identical results. If you put two different vectors in, you get different results. If node A and node B give different vector displacement, itās because theyāre outputting different vectors
For what itās worth, Iāve pointed out these displacement differences in the seemingly identical Noise/Musgrave results and was very firmly told to sit in the corner and be quiet. Now theyāre here again- seems like it might be worth actually paying attention to
I really donāt understand the pushback on helping the userbase transition to the new noise nodeā¦
User asks, āWhere is the musgrave node now?ā We removed it, use the noise node as it can do a Musgrave.
āIs there a Musgrave nodegroup included by default?ā No.
āWhy no default presetā¦?ā Reasons.
āWhat reason?ā We donāt want to. Use the equation and build it yourself.
āI donāt quite understand how to build that equationā¦ what links to what? What does that comma mean? Is there a picture?ā Too bad. No. Download 4.0 if you want to.
Itās fairly obvious that @Hoshinova holds āartistsā in contempt as compared to āmathematiciansā.
Thatās not even my interpretation, thatās a direct quote:
Generally, developers donāt make it their goal to discourage users from using the software, but when you hold the users in contemptā¦ well, I guess thatās the only reasonable goal at that point
After a bit more testing, I donāt think the displacement nodes are the problem. The difference is only there when using the Fac output from the Noise node that was converted from Musgrave when opening a 4.02 file in 4.1, any other type of noise works just fine between 4.02 and 4.1 (todayās build Hash: 3443ded9dfb1)
Iāll try to provide a test file later so you can check that out
There were changes to how normals are computed, and thereās a new displacement implementation in EEVEE. This results in displacement looking different on some meshes, especially one with displacement as extreme as in these examples, where the mesh gets discombobulated. When comparing results, itās useful information to have.
What are you referring to here? In this post earlier in the topic there were seemingly no differences in displacement, only shading.
Youāre misunderstanding. Youāre not supposed to build the equations in the first place but rather get an intuitive feeling of hot the Roughness input works. The equation Roughness = power(Lacunarity, -Dimension) seems rather unintuitive right? Thatās exactly the reason it was removed.
Donāt use it unless you have a good reason to do so.
Please donāt assume such things or put words in peopleās mouths.
A general guideline for Blender features is to have intuitive parameters, to have parameters that are consistent across nodes, and to avoid duplicate functionality.
You can disagree about the right trade-offs here. You think some level of duplication is good to offer more compatibility and easier transition. Thatās a reasonable disagreement to have.
Inferring contempt goes against the guidelines of this forum . So please keep this guideline from the FAQ (here and on blenderartists) in mind. Donāt make this personal.
I donāt see how you came to that conclusion but let me clear things up anyways.
When designing a piece of software certain assumptions about the skills and capabilities of the user base need to be made. The problem with procedural texturing is that it can be fairly mathematical endeavour, yet users without a lot of math knowledge also need to be able to easily create their desired results. Thus the goal has always been to keep things as easy and intuitive as possible, however some unintuitive technicalities always remain.
The equation is one of such unintuitive technicality that is gone now with the new Roughness input. However the old Dimension input did have some deeper mathematical meaning, but if I told you that it was related to the Fractal Dimension would it be helpful knowledge for your workflow in any way?
Thatās why I make such distinctions in the first place. Different user groups have different skills and interest, with certain features specifically targeted towards certain user groups, but I donāt hold any user group contempt.
Generally, developers donāt make it their goal to discourage users from using the software, but when you hold the users in contemptā¦ well, I guess thatās the only reasonable goal at that point
No, quite the opposite. Developers commonly tend to discourage the use of deprecated features.
Brecht, Iām not putting words in mouths; itās illustrative how how many users might take such ā¦lack? of information and/or assistance in both the user manual, and within the application itself. Itās a criticism of lack of easy transition for the userbase, not Hoshinova personally nor you (nor anyone else.)
Above, Baardaap has discussed it, saying:
Imo it would be wise to just distribute a Musgrave nodegroup by default because I foresee an endless stream of questions in #support. However, I think others disagree because of the simpicity of said nodegroup.
Thereās no default grouping included, and above the reasoning is because itās simple to build it. Just because itās simple to build, doesnāt mean that thereās no value in including it as a preset.
I agree with Baardaap, itās opening the door to support issues ā¦ for what need? At face value for someone launching 4.1 and not following this discussion, theyāll just assume Musgrave was removed and thatās the end of it. The release notes mention math, but thatās not the same thing as providing an elegant solution which would solve the issue for users without any need for an email to support.
If a preset is something that is unquestionably a āno!ā, then why not a screenshot of the node setup on the page of the manual?
The argument that I (and I think @Hoshinova) are making is not that itās simple to build so therefore not needed. But rather that itās not needed to build at all for nearly any Blender user. In my opinion, including the mathematically inclined ones.
What I think is needed is to make it easier for users to discover this as the replacement for the Musgrave node. We can do this in the manual, and probably find some way to do it in Blender too. Maybe the noise types can get dedicated entries in a submenu of the node add menu.
Itās also in the release notes Reference/Release Notes/4.1/Rendering - Blender Developer Wiki But really, as Iāve tried to communicate multiple times itās better to just get used to the more intuitive Roughness input instead of forcing the old behavior using the equation.
