Unfortunately not - I lost most of it when I got rid of my Amiga. I have a few .iob files I managed to salvage - that’s about it - but I can’t import them into Blender as there is no Imagine 3D .iob import addon (at least as far as I know).
I used to get a lot of flak on this forum for preferring to use procedural textures instead of image textures where I can, boy how things can change in terms of what an acceptable approach to scene building looks like.
With procedural texturing combined with a revamped Dyntopo system (on the todo list) and Geometry Nodes to automate UV coordinates (so it deforms on animation), we will finally have the non-destructive, non-rigid, non-topological dependent end-to-end workflow that I have been hoping we would get for a long time now.
1 Like
There has been resistance to expand the procedural texture toolset because it might bloat the kernel - but do procedurals need a re-think and taken back to first principles.
A bit like the SDF textures I linked to above - would it be better to have a number of smaller, simpler, basic procedural patterns - along with a set of transforms - that when combined would be much more powerful.
Take the checker or brick textures as an example. Do we really need two procedural textures covering these things - or are they actually derivations/transforms of the same fundamental building blocks (squares and rectangles).
Same with fractal Voronoi. Instead of expanding the feature set of the Voronoi node itself, could the addition of a loop node have actually involved less coding and a smaller kernel - but actually resulted in much greater flexibility as it could be used across multiple textures.
There still is (latest update dec 2023, works in 4.0)
I do agree that shader nodes need more love, many of the new math functions from GN could be ported to shader nodes (random float/vector etc).
I love making procedural textures and would love more nodes, at least we have the new fractal voronoi and noise, thanks to Hoshinova 
Well it is still there basically because there is no alternative, you can not use shader nodes to create brushes (without baking them). I hope it will stay until there is.
Blur is not as easy as it seems, but with white noise you can blur things pretty well mixing it with the tex cords.
Well a lot of people are not happy that the musgrave was merged into noise (personally I like it it has also given the musgrave a colour output.
1 Like
Agreed - more math node options would greatly expand the possibilities of the existing texture nodes.
Again agreed - it is a nice addition. But as I said above, could the same result have been achieved by adding a cycles loop node instead, which would have been much more powerful and much more flexible across multiple texture types (and materials in fact - I used Secrop’s loop node to make dispersive materials by looping over different refraction colours and refractive indices too).
This would have also aligned with the Geonodes paradigm.
I’m not talking about merging. Having one uber-procedural texture node would be a step backwards IMO (I actually don’t like the principled shader for the same reason).
What i’m talking about is actually going simpler and breaking the procedural textures down into their components. You could for example have a “quadrilateral” texture that you then apply various transforms to, in order to make checkers, bricks, tiles, diamonds, herringbone, penrose tiles etc.
In much the same way that geonodes can build complex objects using basic primitives and various transforms.
White noise somehow breaks mip mapping as shown in this topic:
Maybe it would be avoidable if kernel or convolution operations (blur, sharpen) existed in dedicated texture mode instead of being UV edits by shader. Only a speculation though
1 Like
Maybe but I think a lot of work went into optimizing the code, also a loop is a bit abstract for some users. I would not like to have to make a noise texture with math nodes (although it could be done).
Nodes like the brick texture can be recreated with low level math nodes but that would not justify getting rid of it.
Yes it is not real “blur” but I find it useful.
Yet we have just got exactly that in geonodes.
You can of course achieve the same effect by duplicating nodes and overlaying them resulting in complex node trees - but the same is true in geonodes. The loop node just simplifies things.
1 Like
Ha ha, yes and the voronoi node does as well. 
Sorry I am reading while responding, yes that sounds good but I would keep the higher level nodes as-well.
The difference with geonodes is that it runs on the CPU, and it only needs to deal with a few million vertices, looping maybe hundreds of times.
Cycles is GPU accelerated, which makes coding much more complex, and it needs to deal with millions of pixels, for dozens of bounces, and thousands of samples, per frame.
Try running a geonode tree on a 8.2 million vertex mesh with a thousand iterations a frame and you will appreciate what a different beast geonodes is vs cycles.
1 Like
Fortunately, the GPU compilers can handle bigger kernels than they could in the past, meaning much of the lost procedural functionality from BI has made its way back at least in some form.
However, yes, we can’t just pile in new texture types and texturing operations without a visual example of what they can do for users. A good example of how to not introduce a new texture type is this thread on devtalk.
Raiko Texture [NOT a feedback thread!] - Contributing to Blender - Developer Forum
A new texture that sounds interesting and from a dev. who has shown coding experience, but the issue is we have a proposal before knowing what the texture does and how it works and with no means to try it.
To be fair they were not “introducing” a new texture, it was more a question of how to implement the node design.
The first option presented (which the OP stated was their prefered option) was to:
1. Ignore the fact that there are duplicate features and implement Raiko Texture as is.
Which basically means not touching the existing voronoi and making a new texture node.
I agree that they could have used a better strategy, they were jumping the gun without showing examples, but so were some of the responses.
Personally I look forward to seeing what they come up with. Maybe it will make it, maybe not, it could be really cool - or not, we simply do not know until examples are shown.
I can understand why some might read the responses to the initial, and think of gun jumping… but with this particular developer, I felt it was paramount to immediately shut down talk of certain options, due to how the deletion of the Musgrave noise texture did not go the way I understood it would (which I did ultimately support, and now wish I had not.)
Although I didn’t do extensive testing around this - when I used Secrop’s python loop node - I actually found it to be around 7% faster in the cases I did test than building the manual node tree (e.g. when I created a loop dispersion glass node - rather than using the usual add method).
I certainly didn’t experience a massive performance hit when using it.
Didn’t something like that happen with the mandlebrot/lyapunov texture node. It got coded and built without any real use case being present (beyond doing Mandlebrot and Lyapunov renders).
When people started testing it - it’s usefulness seemed extremely limited and it ultimately got dropped.
This is entirely expected, as the white noise destroys the derivatives. Perhaps a custom mip socket could help.
There are some movements about textures. For example Gabor texture is in the works and at good stage. Brecht showed interest in adding that.
As for tools such as loop that exists in geonodes, its just a matter of will and priorities from Blender to implement those in other node editors. For starters we dont even have fields in materials. You cant create one asset and pass informations such as color from outside per usage withour either duplicating materials or using custom properties.
Geonodes and assets team have laid down great design of how Blender should function, how modular, asset-based workflow should be created. Now its matter of adapting older editors to that. For example Hans created design for shader nodes fields, but he has so many things on the plate with higher priority its a matter of years til he can get to that. So were left with community contributors to work on those.
Just yesterday boolean and integer sockets were merged for groups. Imagine that. And thats just for groups internal nodes dont have them. You cant expose ambient occlusion “Inside” outside node group. Anything build with shader nodes is a hack. There is no other way.
Repeat zone, math expressions, object inputs, everything is added to geonodes. But someone is needed to port them to shader nodes and compositor
1 Like
Absolutely agree. It is good to keep talking about these topics though, to highlight that they are still important.
Some things that would massively increase the number of possibilities for Cycles materials would be the aforementioned loop node. But also a generalised shader math node (we have add and mix, but subtract, multiply etc would greatly increase the range of possibilities).
I did have a solution for shader subtraction a few years ago and got some very interesting results - unfortunately, recent updates to blender mean that solution no longer works.
Maybe I am the odd one out, but I think it went very well, when I save a file with a musgrave texture in 3.5 it comes out the same in 4.0. Plus we now have colour and distortion for musgrave.
I do not see any problem with it but I do see advantages.
Most of the discussion on that change (apart from a couple of bugs which were fixed) boiled down to “I can not enter the same values and get the same results”. Which although true does not mean you can not get the same results entering other values.
Changing the “displacement” input for the roughness input to me is also unifying the criteria across different nodes.
The roughness input is consistent and predictable with the noise texture and the voronoi texture.
Musgrave is one of my favorite types of noise for dirt/grunge, I have no problem with the change and find it easy to use.
2 Likes