NumberFlow, visual editor for procedural textures

NumberFlow is a visual node-based editor extension that allows you to design your own procedural textures right inside Unity. You can generate textures and animations at runtime, providing virtually limitless content while requiring very little storage space. The full source code is included.

Buy Now from the Asset Store (affiliate link).

Download Free for non-commercial use from the product web page.

Visit the product web page for more information, web player demos, and documentation.

Frequently Asked Questions

Does it require Unity Pro?
No. NumberFlow works with both the free and Pro versions of Unity. It also looks nice with both the Light and Dark skin.

Can I use procedural textures while editing my scenes?
Yes. With the help of a Diagram Material Manager, you can use materials with procedural textures in edit mode.

Do I need to program to use it?
No. You design diagrams visually by dragging, configuring, and connecting nodes. You can link them materials with a Diagram Material Manager. You can also export them to PNG images and use those like any other texture.

Does it run on mobiles?
Yes. It works on iOS, Android, and any other platform.

Does it run on Flash?
Don't count on it. It might, but NumberFlow is not supported for Unity's discontinued Flash export.

Does it use the GPU?
No. NumberFlow runs fully on the CPU.

Can I use texture animations?
Yes, but it is only practical to do realtime texture animation in very limited cases. You also need to do some scripting yourself. The web player demos give a good impression of how nonstop texture generation strains the CPU. The Gallery demo has some examples of using shaders for animation, which is a lot cheaper.

How can I generate textures as fast as possible?
The fastest way is to design in NumberFlow and then reproduce the result with your own code. Then you can eliminate the overhead of the diagram structure and incorporate all kinds of case-specific optimizations. Whether this is a wise use of development time is questionable.

How can I improve performance?
There are many ways to be smart about this. Here are some tips, but the main idea is to use less more creatively. Use a Diagram Material Manager or your own thread to compute textures. Generate once at load time. Use a lower resolution. Use less frames for animations. Use pregenerated short looping animations. Use multiple simple images for more complex effects. Use less octaves of noise. Use square distances.

Is it memory friendly?
Yes. Once a diagram is initialized it allocates no memory while generating textures. Of course the textures themselves do take up memory, as do any color arrays that you use. Make sure to set textures that won't change after generation to be no longer readable.

Can I generate compressed textures at runtime?
Textures need to have the ARGB32, RGB24, or Alpha8 format, otherwise their pixels cannot be set. However, you can use the Texture2D.Compress method afterwards to compress to DXT1 or DXT5, if available.

Does it use Allegorithmic's Substance technology?
No. NumberFlow is a visual scripting tool for designing procedural textures yourself, right inside Unity. The textures are generated by scripts written in C#. There is no custom data format, no native libaries, and no external tool needed.

Can it be used with JavaScript/UnityScript and Boo?
Yes. Though NumberFlow is written in C#, you can use it just fine with the other scripting languages.

Is the source code available?
Yes. When you buy NumberFlow you get all source code. The free version has mostly precompiled DLLs.

Buy Now from the Asset Store (affiliate link).

Download Free for non-commercial use from the product web page.

 

Really nice for the good price. And the fireball - so beautiful

 

This is super impressive. I have a question though. Is Numberflow multithreaded and if so how well does it scale across threads ? Does it automatically use as many cores as the device has or do you need to specify how many it should use. The reason I ask is that I would like to know how well it scales on mobile. If I run it on a quad core mobile chip will it run on 4 cores and be faster than running it on a single core mobile chip automatically or would I need to explicitly tell it to run on 4 cores. The reason I ask is that I noticed in your demo there is the computational spread option. I'm unclear whether that is spreading the computation across multiple cores of a cpu or asking it to spread the computation across multiple frames of game time. Also the fact that in the demo you specify how to spread the computation makes me wonder what it's default behaviour is. Ideally it would have a load balancer that would automatically spread the work across multiple threads based on how busy they were, is that the case ?

I've also got a suggestion to make NumberFlow more user friendly. I think the most useful feature of NumberFlow would be linking it's runtime generated textures to unity materials. It looks like this is possible but at the moment you have to do it in code. It would be great if you added a button in a similiar way to the one that exports to png but one that exports a script that automaticaly links the diagrams texture output to the current gameobjects material. Then all a user would have to do would be drag that script to the gameobject they want to use the texture on and it would be used by its shader. The script could be generated so that is displayed and allowed the user to vary any of the input variables associated with the diagram it was linked to in unity's inspector window as well as to specify what texture channel it should link to on the objects material. You could also design it so that a user could drag more than one of these scripts onto a game object because they may want to use them in multiple texture channels on a shader so that they could combine multiple diagrams into one shader and then use the gpu to perform any functions that would combine them that would be too expensive to do on the cpu with NumberFlow to combine the diagrams together. You could even try and get really fancy and add options in the generated scripts that let the user specify how the texture in the diagram is generated in a similiar way to what can be done with substances. You could have options to specify whether they are generated on level load , run in realtime , run once and then cached in memory or run once and saved to storage so the next time the application loads the diagram doesn't need to even use the diagrams and their only purpose being to keep the required download size down.

 

@V0odo0: The fireball is my favorite too!

@IanStanbridge: NumberFlow diagrams can be run in separate threads. (Caveat: textures must be supplied as Color arrays.) However, you cannot use multiple threads to compute a single diagram, because that will screw up its internal data. So at most one thread per diagram.

The demo distributes the computation over multiple frames, not threads. It gives you manual control over how much frames to use, but it can also be adaptive, which is what the editor does.

I can put some threading stuff it there, but a thread management solution is kinda out of scope. That's typically a stand-alone thing that people use for their entire app and would want NumberFlow to work with, not roll its own version.

The initial NumberFlow version is basically the minimum needed to get it out there, but I definitely want to add functionality and improve usability. Your suggestions are very nice and I really want people to bring more! I am investigating how to integrate better with materials but the options are limited. I'll keep working though. Code generation is also on my mind, it was just totally out of scope for 1.0. Buy NumberFlow, and updates will come!

 

I have updated the diagram demo to use multithreading instead of spreading computation over multiple frames. This change will be included in version 1.0.2, which should come out somewhere later this week. The introductory price will also end then, so grab it quick!

 

Very cool package,

Just bought and imported into 4.3

Assets/Plugins/Catlike Coding/NumberFlow/Functions/FloatFunctions.cs(297,47): error CS0120: An object reference is required to access non-static member `Perlin.Noise(float, float, float)'

 

Regarding multi-threading..

I am using Loom Multithreading from the asset store. Would you consider in a future update to add support for Loom Multi-threading?

Cheers.

 

@rocki: That is a weird error, as that method signature does not match what's being used. Can you check whether the code does resolve to CatlikeCoding.Math.Perlin? Does it fail for all the noise calls?

I am not familiar with Loom but I looked through its API. It looks like you can just fire up a thread with a method that fills a color array and calls back to the main thread when you're ready to fill a texture. Is there some specific Loom stuff I should hook into?

 

Got it working... turns out there was another plugin that has Perlin.cs in the plugin folder. Seems strange that even though your project is in it's own namespace that unity should use another Perlin.cs

As for Loom, what I meant about supporting Loom is that for users of NumberFlow that have Loom, they do not have to do anything, just start up the package and it's already multithreading with Loom. Perhaps there could be a cross promotion between the 2 packages as they are really a great fit for one another.

Btw, is there a way to do distance maps in the package.

Really enjoying playing with the package... Very Flexible and Great Potential... Super Nice.

 

Found a very interesting link on Amortized Noise.

"A new noise generation algorithm called amortized noise generates smooth noise using dynamic programming techniques to amortize the cost of floating point multiplications over neighboring points."

http://larc.unt.edu/ian/research/amortizednoise/

 

@rocki: Thank you for checking! I did some tests and it clashes when the script has the same name, it is also in the Plugins folder, and it is not inside a namespace. I'll make sure it won't clash anymore in 1.0.2 by using the fully qualified type.

I could include add-on functionality that conveniently hooks into Loom. Not automatic, as that might well worsen performance and screw things up, but certainly optional. I will investigate this.

Computing distance maps from arbitrary textures isn't a good fit. You're better off with a specialized algorithm. I do happen to have a free distance map generator for use in Unity's editor, which might be useful.

I'm not sure that amortized noise is worth it, as it seems to rely on a lot of cached data. The paper doesn't do much explaining, so I'll have to study the code.

Oh, and if you design something neat, I wanna see!

 

Would be so awesome if you could make NumberFlow and Loom integration more convenient.

Nice Distance Map Generator, will try it out.

Sure thing, if I have something cool, definitely will show you.

Cheers.

 

hey,
first: this is a great package and for this price a real steal.

i had the same issue with the procudral examples (from unity) package. so its not that rare . i don't know why unity gives precedence to the other class instead of yours.

factor 2 or 3 faster is at least worth the look imo . there is also a very extensive gpu-noise package from jesta. it would be great if this could be included/linked once it supports gpu->cpu communication (in the works).

some remarks, ideas and feature suggestions:
complex diagrams get a mess real quickly so it would be great to have a string field per node where the user can enter a "variable name" (just for user), comments and remarks. just to remember what a node is supposed to do.
pi should be included as constant (maybe also e). as well as a function for arcussinus and arcuscosinus (and maybe tangens + arcustangens).
the currently selected node should be more "visible" maybe through another color or a frame.
also you could highlight all links which lead to the current selected node so its easier to "follow" the values (where they come from) when there are several "paths".
when i select a node it shows "linked" in the detail view. it would be usefull to click on this and the linked node is selected (or have a small button beside to do this) to traverse backwards.
the v coordinate goes from bottom (0) to top (1). i don't know if this is standard behavior but at least it could be documented somewhere . for my purpose i have to use 1-v.
an organisatorical feature would be some rectangular container (nameable/comment) where i can put nodes inside and then only move the container to move all nodes inside accordingly. this way one could name the parts of an "equation" and keep it organized in one place.
noise has parameter lacunacity what should be lacunarity (r) if i'm not mistaken (not english native speaker).
a gradient should not have a solid color by default. i was wondering why my noise was not working as expected. so a default gradient (fe black/white) would at least prevent this and make issues more obvious.

now what i have done with it. i created a diagram for a planettexture that shall be mapped on a sphere. so i calculate the position of each pixel in 3d space and then feed this position as direction vector into the noise engine to grab a noise value there. by using this approach seamless planetary surfaces can be achieved which you see mapped on a icosphere (lat/long sphere has texture issues at poles, much reduced but still not gone).
consider the distortions of the flat texture at top and bottom (poles) which is because the pixels are much closer together there. the gradient is simple red for 0 and white for 1.


my attempts are not finished yet and i have plans for different planet types, planetary ring textures, a corona and clouds. just want to let all people know that your tool is a great help, easy to use and highly recommended for any type of prototyping (when performance is ok also for production). its a pleasure to work with (once you get the concept) as you directly see the effects of your changes.

questions:
i also want to achieve craters. do you have an idea how this can be achieved with your package (maybe with custom nodes)? can a region be set to a certain value? you have a function distance from center so a distance from arbitrary point maybe would be usefull. maybe also creating a "mean"value for a region.
what about creating a normal map? or do i need external tool for it? (would be ok).
do unlinked nodes affect performance? i ask because its often required to show some intermediate result or to test something and its a hassle to always create the output again.
when is the diagram saved? when the scene is saved? after each change?

 

Work for 1.0.2 is nearly done. I've added various flavors of voronoi noise. Though slower than Perlin noise, it enables lots of interesting effects.



@exiguous: Ah, you bought it, and I am glad to hear you like it!

I admit that the editor is currently quite bare-bones. Figuring out how to improve the workspace is a real challenge, because it needs to stay as simple as possible, but I have some ideas. The selected node and its connections have a slightly different color, but you're right in that it's not visible enough. Turning "linked" into a button sounds like a good idea, thanks!

I'm using OpenGL's UV convention, which has (0,0) at the bottom left. Here you can't please everyone, but at least there's 1 - V.

Cool that's you're texturing planets! I'm going to include sphere coordinates nodes somewhere in the future, but I've yet to decide what systems to use. You're using the obvious one here, but as you mentioned the poles are low quality.

I can definitely include a PI constant node, but you can also use Sinusoid nodes instead of Sine and Cosine. It has 2PI conveniently factored in already.

Can you achieve craters? I'd say yes, but can you elaborate? Do you want to place features at exact points, or leave it up to noise? You can get the distance to a point by subtraction and getting the (square)length of the result, which you can then use to modulate some effect.

Can you create normal maps? Yes, but there are many ways to do so. The Terrain demo uses a two-step approach where one diagram creates a height field and another computes normals from that. See the "Normals Heights" diagram. There is another "Terrain" diagram in the other demo, which calculates heights, colors, rough normals, and lighting in one go. Nice to show off, but not practical.

Do unlinked nodes affect performance? No. Only nodes leading to the output node are part of the computation. I regularly work with diagrams that have
huge dead chunks in them.

When is the diagram saved? It's saved when you save the scene.

 

i know that you can't please anyone. i thought there is a standard as this way its counter-intuitive for me. but probably there are standards to cover all possibilities and this is like no standard at all . i also wantet to mention this for other people needing this information. so it was not entirely a complain .

this problem is caused by the mesh, not the texture or the uv coordinates. the only way to avoid would be to use a sphere based on a cube with a cubemap texture mapped on it. but then the coordinate calculation is not straight foward any more. but when you would make a solid mapping of cubemap-uv to 3d coordinates and vice versa i would not complain.

the placing of those features can be random, maybe influenced by a linked value. for example there could me more craters in higher regions and none on sea level.

i have no idea how to "loop" over the data. so in general i would determine the position of the crater center then find all pixel within its radius and adjust their value. from my understanding your package does calculate each pixel once? i don't know how to include several potential influences in the diagram. as mentioned i would not care to do it in a custom node but you stated that those should not rely on persistent states (i guess because of distributed calculation). so it is difficult to keep a list of crater data or maybe i just understand the workings wrong. thats why i ask if you see a method/aproach that fits into the internal working of your package.

is there a save check so when i (accidentially) close the diagram or open another (by selecting it). so is it saved in background, am i asked or is my work since last manual scene-save lost?

another thing i would like to understand is how your fractal noise samples the perlin coordinates in relation to the point put in as parameter.
so imagine i have 2 octaves an the pixel koordinates are given as input on the x-z-plane. so pixel 0,0 is used to sample perlin at position 0,0,0. pixel 1,1 samples at 1,0,1 and so on. so where is the value for the second octave with doubled frequency taken from? 0,0,0 and 2,0,2 in the example? so is the frequency simply the factor/multiplicator for the coordinates? i ask because the noise wraps around without a seam out of the box and want to understand why. i know its hard to explain/understand.

anyway thanks for your explanations and input.
btw i always prefer the documentation as a pdf together with the package. a pdf can be searched for keywords but for information on different webpages this is more difficult/inconvenient.
and i hope you see my complains not as nagging but as constructive critics and suggestions for improvements. in the end you decide what matches your "vision" of the product and what not. you must not include everything just to make me happy (i have paid already ).

 

@exiguous: You aren't nagging, I greatly appreciate your input!

Indeed you don't loop over data. What you do is blend. For example, you can design something that looks like craters all over the place, then use altitude to fade it in or out on top of you base altitude. The upcoming voronoi noise would be a good candidate for generating a crater landscape.

Here I added one big hole by factoring it into some noise.


The Perlin noise is solid 3D noise, it's sampled at whatever point you provide. The frequency is indeed used to scale this coordinate. Only the tiling noise variants have to do some extra trickery. Your planet texture is seamless because you wrap it around a sphere in 3D.

It wasn't really correct of me to say it's saved when you save the scene. The diagrams are assets and as such cannot be lost unless you delete them from your file system. You won't lose work when you close them. Unity saves assets at various moments, from what I remember including on scene save and application quit. The only point you could lose works would be when Unity crashes before it saves its assets.

I don't like PDFs and much prefer web pages myself. Searching in documents is so often riddled with false positives. Web pages are far easier to maintain for me. All the links, animations, web player, downloads, etcetera are also right there. I could add a site search though.

 

just to make sure i'm not too demanding .

thanks for the example. i hope i find some time on the weekend to investigate it in detail.

i know this issue. i had already created seamless textures with simplex noise in code a while back. i just thought it should only work for the point itself. in my tests (with simplex) i used the position on the unit sphere as direction and scaled it to the length of the radius i wanted to sample from for each octave. so a short radius has a small circumferrence and thus samples a low frequency noise.
i just wondered why it worked with all octaves in your noise. it seems that its done the same way in your method by uniformly scaling the point in all 3 directions.

ok. i just wondered when i selected another diagram in the project view it got displayed immediately without clicking "pen in editor". this is usefull for quick reference of examples etc but only as long as the previous diagram is not lost .

i understand this. with a site search the issue is gone anyway. and there comes an "online documentation" to mind where you press a question mark beside a command and land on the page when you press it. but i'm just thinking loud .

 

hey Jasper,
i have followed your big hole example.
your example has one crater and thats my issue how to achieve multiple ones? its hard to understand for me when i cannot loop over data and refer to other data (neighbouring pixels).
am i right that i need to do a blend for each crater i want to have? so my theoretical setup is to have a diagram that produces the general surface in a texture. then i create a loop with the number of craters iterations and feed the texture to another diagram which blends in one crater per iteration at an arbitrary position. is this the setup you meant? one blend per crater might be very time consuming as the whole texture is touched. maybe its better to do it in code and only touch the pixels required.
also i don't know how to wrap around the texture when a crater is at the border but reaches the "other" side.

more questions:
how can i seed the perlin noise?
as for most cases noise is needed between 0 and 1 you could do the scale to 0-1 internally (in a special node or by checkmark).
in what form is an input gradient defined? is it a 1d texture?

thanks alot.

Edit: another "issue" is that the pixel distance is not equal to the 3d space distance. so when i simply use it the craters would look distorted. so it seems that craters in my use case would be too hard to achieve with your tool. this is not bad as it cannot be suited for everything. so i'll do the craters in code and use the diagrams for texture, heightmap, normalmap and maybe clouds.

 

@exiguous: Doing it once per crater is indeed not a good idea. Instead, you want to generate craters with noise as well. Below I've done just that with NumberFlow 1.0.2. I used three voronoi noise nodes to generate spheres at different sizes and subtracted them from the terrain noise.



As it's all 3D this approach also works fine when combined with a sphere texture. The screenshot shows a 3x3 tiled preview.



The noise uses a permutation table. You cannot seed it, instead you can offset the sample point so you end up using a different part of the domain. Like adding 123 to Z. You have a 256-unit cube to move around in, beyond that it will repeat. The Perlin noise matches the reference, which is centered around zero and has an effective range of about -0.7 to 0.7 for one octave. Transforming it to a 0-1 range is expensive in the general case, better define your own constant factor that works. Another useful trick is to use a "Float / Range / Pingpong 01" node to make it bounce between 0 and 1.

 

thanks for your example. so i wait until 1.0.2. arrives. btw to make 1 crater per blend was not because i like the method but because of lack of understanding how this blending works. thats why i asked about looping over data. and without the voronoi noise (which was not released then) i did see no other possibility. but thanks for showing me the way.

for simplex noise the table contained the numbers from 0 to 256 iirc and i used a seed for unitys random number generator to fill the list in pseudorandom order with all the numbers. this way the noise should look different at same position with different seeds. or does the tabkle need to be in this fix form for a certain reason?

 

1.0.2 could arrive any moment now, when the asset store team is done playing with it. That will also be the end of the introductory price period.

@exiguous: It is a static doubled 256-entry permutation table. It is used by all the noise functions. Technically you could change it by modifying the code, but that would change the result of all noise samples, not for just one diagram. It is this way both for performance and practicality. Adding an offset vector in front of a node is easy and understandable. Tiling noise nodes even have an offset parameter built-in. The non-tiling ones don't have it because it's often not needed (offsetting Z gives lots of variety for flat textures). So it's good that you jumped straight into planet textures as it leads to these interesting discussions.

 

I caught a bug before 1.0.2 had been accepted and resubmitted it. This will undoubtedly delay the release, so apologies for that. At least you won't be troubled by this bug.

 

The update has been accepted and is now available on the asset store!

Here's some tiling voronoi cells to celebrate.

 

hey jasper,
quite a price jump for your asset so i'm happy i purchased it before .

as usual i start with my "complains":
online documentation does not contain voronoi noise yet.
your signature still mentions the "introductory price".

now i'm on my way to figure out your craters-example. is there any chance that you can pm me your diagram (or a link to it) as i have difficulties to figure out the values used and the meaning behind some nodes. if not what is the multiplier between curve and addadd (+ +) for?
another feature request/suggestion comes to mind: (optionally) displaying fix values behind the parameter name in the diagram (not just when selected) so the multiplier would show B 0.1 fe.
another helpfull feature would be to have the range of values displayed. so a noisenode could be named perlin [-1, 1] and when the next node multiplies it with 5 it shows x [-5, 5]. so a node remembers the min + max values of all pixels and displays them. i know these things take more screen space and thus make diagrams more confusing. but they could be optional and the min max thing only displayed for the selected node. but i think this could add to better understanding and less confusion and thus allows better workflow. i often see me creating a gradient and displaying some intermediate nodes just to make sure that they look like i expect them to look.
may i ask for a roadmap so what plans/ideas you have for future extensions?

anyway i like the new noise and it can be utilized for quite many effects. simply changing one parameter alters the look significantly.
i have a question to the vornonoi noise. in the picture are 2 "craters" but they do not overlap but have a straight line between them. do you have an idea how to prevent that? choose the parameters so they have enough distance?

 

@exiguous: Your sharp eyes are appreciated! Signature's been changed, documentation is in progress.

I guess an explanation of the crater diagram is most useful. Here it is again.



The sinusoids do the exact same stuff as your sines.
The Perlin noise has frequency 1, 5 octaves, with lacunarity 2.3 and 0.5 persistence. At * 0.5 + 0.5 it is used as the base terrain, and at * 0.2 + 1 it is used as scale to distort the voronoi noise nodes a bit.
The Voronoi nodes have one octave and frequencies 0.5, 2, and 3 from top to bottom.
The curve goes from -0.5 zero to about 0.15 and then back to zero. So it results in a pit with a little ridge.
The curves are scaled per noise node to control how much of a dent each each of them makes, at 1.2, 0.75, and 0.3. So the big one goes deep but the small ones are shallow. Could've used three different curves instead as well, but this was less work.

Indeed the Voronoi cells don't overlap. You have to adjust your gradient so it reaches black before they touch. The crater curve in the above diagram is in the 0-0.2 range, for example. It's never a guarantee, though. To make overlapping craters, you'll have to use separate noise nodes.

Showing fixed values really troublesome but a good suggestion. I'll have to experiment a bit.

Here's the current roadmap, roughly.

1.0.x releases

• More node types.
• Interface improvements.
• More example diagrams.
• Documentation improvements.

1.1 release

• Node grouping.
• Other interface adjustments.
• Better integration with materials.

future releases

• More advanced multithreading.
• Potential integration with other tools.
• Experimental stuff.

I'd like to get at least 1.0.3 out before the end of the year, but it depends on a lot of factors. Feedback plays a big role in it, and I can't thank you enough for that as most people keep silent. If you could also rate and review NumberFlow on the asset store, that would be a great help too!

 

thanks. i also apreciate your patience and steady help + explanations.

i'm busy the next days and need to find some time for your details. will report back then.

rating is done already and review will follow soon.

 

I have updated the node documentation. Noise now has its own page and includes the Voronoi nodes. I've also added example images for lots of nodes.

I'm now working on adding more nodes and interface stuff.

@exiguous: Thank you very much!

 

hey jasper,
i have set my attempts to create planets on halt as i have discovered a package what does this already quite in the fashion i need. so i'm currently evaluating this asset and think the time is spent better than starting from scratch with my "pathetic" attempts.
however. i'm still happy to have your package at hand and plan to use it for other occasions.
keep up the good work.

 

@exiguous: It's definitely a good idea to use a specialized package! If you also want planet meshes, LOD, saving, and so on, then that tool could save you a lot of work.

Meanwhile, I've put put fixed numeric values in front of their connectors in the diagram, and it turned out to be quite serviceable. Here's an example, which also shows off a handy new node for longitude/latitude mapping.



And this is the resulting texture put on a sphere with a Bumped Specular shader. I used the alpha channel to generate a normal map.

 

thats the intention. albeit i might miss some learning experience i value the progress higher.

i'm glad that i could contribute to your package by inspiring you with some "complaints" . it's often the low-brow users who see what is missing to improve something.

 

It's Holiday Time! NumberFlow is now available for $10!


(Image created with NumberFlow. The text came from a distance map input texture.)

I've also been working on a manager class that links diagrams and materials, so you can see the textures in the scene while not in play mode. This makes it practical to incorporate them into your scene design. It already works, but it needs a lot more polish before I can make it available, which is my top priority right now.

 

May your neurons fire lots in 2014!

 

I'm currently working on NumberFlow 1.1, which will make it a lot easier to use generated textures in your scenes. Upcoming features are multiple outputs per diagram, simple normal map generation, and linking diagrams to materials. And finally to show the generated textures in your scene while in edit mode, making it easy to incorporate them into your levels.

 

Sounds like it's going to be a great update. Any idea roughly when it is likely to be released, the using your diagrams to manipulate materials was what I was most interested in using it for.

 

Hi Jasper

I purchased Numberflow yesterday and been trying to wrap my head around its operation. I am looking into fractal based imaging but not sure if Numberflow is equipt to handle fractal processing yet (Edit: it not as it does not allow looping which is paramount for fractal processing). Anyway I just thought I would add some suggestions for usability on the upcoming releases.

1. Multiple selection of nodes. without this you have to move nodes induvidually on the canvas.
2. Preview/debug Node. Not my idea but found it extreamly useful in blender. Allowed you to see the effects and progress of your texture at different stages of the flowDiagram. Very similar to what you have with the output color node, but instead of having a preview at the low right corner of the canvas it could be embeded in the node itself. useful for debugging. Speaking of which.. may be useful to include float/int/v3 in another probe node for debuging purposes.. could all be under a single debug node.

3. Node grouping so that you can group nodes into a single node to simplyfy diagram and for re-usablity ... much like you would create a function in code.
4. Comments grouping node which is resizable and lays behind the other nodes also has place for text input so so you can add comments. Same as uScript implimentation.

5. Variable visibility. Just a panel where we can see all the variables you created in the node graph for internal reference which is different to the next suggestion..
6. external access to created variables. kind of the same as seeing exposed/public variables in the inspector. This allows you to expose variables for tweeking purposes outside the graph. Also nice if you want to re-use or distribute your flow graph and just make minore adjustments to fit your needs.
7.Fractal processing...

Well thats all the ideas I have for now. Will advise if anymore come to mind. Thanks for a great product though and I am eager to get back to playing around with it.

 

@IanStanbridge: Right now I'd say it might be live at the end of the month. Converting my separate prototypes into a polished 1.1 release that won't destroy anyone's diagrams will take some time.

@Charl Marais: Indeed there are no loops. They complicate matters a lot, have scary potential to freeze Unity with user-created endless loops, and I haven't yet thought up a good way to support them in general. Fractal-based imaging is possible with the help of the noise nodes. Their multiple frequencies are as close to loops as you can get. If you need another noise type you could program it as a custom node, though that's of course not as user-friendly.

Thank you for your suggestions!
Points 1, 3, and 4 are definitely on the roadmap.
Point 2 is something I have yet to investigate but would like to add. The hard part here is figuring out what's meaningful non-color data to show and how this could be done.
Concerning point 5, the inputs will definitely become more visible and will be added to the inspector at some point.
For point 6, you can access the inputs through scripting at run-time, but you'd have to duplicate a diagram to permanently have two different versions of it. When they get linked to materials, I could add configuration per material, but this won't be in 1.1 yet.
And for point 7, you have the noise and custom nodes.

 

1.1 Feature Preview

Multiple outputs and normal map generation are now fully functional, though the code is still a mess.

Normals are generated by interpreting the alpha channel as a height field in a post-processing step. I added a convenient single-value output node as well.

 

1.1 Feature Preview

Here are two procedural stone textures shown while in edit mode. All you need is a manager object to link diagrams to materials. I discovered that using a prefab is easiest, as each prefab change can be used to recreate the textures. And it all works without a custom editor, though I'll make one anyway to improve its visuals.

 

I have created the NumberFlow Gallery, a simple scene showing some materials created with NumberFlow and using the upcoming manager. It's still very crude, but it should grow over time and become pretty.



@SOULS STUDIOS: 1) It's not infinite, as you're generating textures and thus limited to the pixels in them. Get too close and they become blocky. Keep in mind that we're limited to multi-octave noise. It's a far cry from realtime infinite fractals.

Amplify allows you to easily use an enormous amount of static texture data. NumberFlow allows you to use textures that require almost no storage and can be configured to produce varying results. Those are very different use cases.

2) I don't know whether managed NumberFlow textures could be used directly in the editor of Shader Forge. It depends on how it manages its materials. If it doesn't work, you'd need to export textures and use those in the editor as previews. I will keep looking for ways to improve the previewing of materials, but node-based shader editing features are out of scope for NumberFlow for the foreseeable future, exactly because of products like Shader Forge.

 

NumberFlow version 1.1 is now pending review!

If you're curious, here is the new Getting started with NumberFlow document, which explains how to use the new multiple outputs and the diagram material manager.

I decided to leave the custom editor for the manager out of this release. It is fully functional without it, so it's not worth a delay. I can now take my time to make it pretty.

 

NumberFlow 1.1 is now available on the asset store!

Unexpectedly, the update has been approved within a day! This is really nice, but I still have to update the online documentation to version 1.1, so right now it's a little out of date. I'm working on it now.

Here are the release notes.

Constant numeric values are now shown in diagrams.
Added support for multiple texture outputs per diagram.
Added support for normal map creation as a post process step.
Added versions of Diagram.Fill and Diagram.FillRows method that fill multiple pixel buffers at once or allow you to choose an output.
Obsoleted Diagram.Fill(Texture2D), Diagram.FillRow, and Diagram.FillInSteps methods.
Added Diagram.PostProcess.
You can now use a diagram material manager to link diagrams to materials in your scenes. The textures will be generated both in play mode and in edit mode.
Added DiagramMaterialManager and ScenePersistentObject components.
Added Gallery example scene.
Added Value noise nodes and methods.
Added Colors / Lerp node.
Added Floats / * + Multiply Add node.
Added Floats / With 1 nodes.
Added Floats / Relative nodes.
Added nodes to Vector3s / Axes that combine X and Y.
Optimized some code.
Fixed a bug in GetXYClamped.
Updated the example scenes.
Rewrote the Getting started with NumberFlow document.

 

hey Jasper,
good to see the progress of the package. some nice new features included. i like especially the normal map generation.
have you considered to support 3d textures somewhen in the future? this is not a feature request i'm just curious what you think about it. as they can just be filled procedurally right now this would match for numberflow perfectly.

 

@exiguous: Glad to see you're still around!

You can easily use NumberFlow to make 3D textures with a little scripting, but there's no way to preview them in 3D. The big question is how that could be done in a meaningful way. 3D textures are cool, but I don't see any demand for them so it's not on the roadmap yet. If you're wonder what other texture stuff is on the roadmap: cube maps!

 

sure am i lurking in your thread . the planetary terrain package offers sophisticated terrain generation and lod manipulation. but it still need to be fed with textures and this is where your package comes into play. for variety, storage reduction, flexibility and most importantly because i suck at art number flow will have the burden to produce them. i just wait until the other package recives the next update and then i incorporate both packages and try to make then work together. so just because i don't need number flow to generate height maps any more does NOT mean i don't need it for other stuff.

good to know. this blog shows a spaceship with a 3d texture applied (unfortunately with little information) and i had the desire to also try this and naturally thought of number flow. but this is late in the pipe and not urgent for me (albeit interesting to see if it works).

i imagine a rotateable block and you can choose each axis and there is a texture with the slice displayed. the position of the texture/slice can be slided much like prints of a tomography.

yes, i wonder why they are so "underestimated". probably because they are so hard to handle and have no tool support and because they require another unconventional workflow. i also thought about making space nebulas into 3d textures with number flow but this would require a raymarching? shader and the attempts i have seen so far does not seem to be capable of such things. but sooner or later it will come .

nice. this could be utilized for skybox creation. do you have any advanced usecases in mind i'm not aware of?

anyway, it's good to see how the package evolves. there have been several packages with visual design capability released lately. so the unity toolset advances more and more and offers new opportunities and better workflow. i really like that. thanks for contributing to it.

 

By the way, I recently added a demo for the Math library. It is part of NumberFlow but useful on its own when not working with textures.



@exiguous: The procedure to generate a 3D texture would be to design a texture with an input for the third dimension, then use a script to generate one texture per step while going from zero to one.

If you want to texture arbitrary geometry based on world or object space instead of relying on UV, a procedural shader is probably your best bet. While you can sample a 3D texture to paint a surface, you'd typically use it for see-through volumetric things that justify the huge memory requirements. Rendering volumetric effects can be done by layering many billboards, but it results in massive overdraw and placement is nontrivial. The only practical application of 3D textures I have any experience with in Unity is color correction lookup tables, which can be low-res and are only sampled once per pixel.

Cube maps can be used for skyboxes indeed, and also for reflections, and lookup tables. And of particular interest to you, they are also used for sphere and planetary texturing, as they have superior texel distribution and less distortion compared to longitude-latitude unwraps.

It's definitely cool that Unity is getting more and more visual design support and I am happy to play a small part in that!

 

yes, i have successfully reproduced the example code by Aras and it rendered a colorfull sphere. but this was only a proof of concept to keep in mind as i'm currently working on other stuff.

the memory requirements are not an issue for me as i want to "tile" the texure so i only need 1/8 sector (all axis positive) and negative coordinates are mapped into that range (mirrored). also the extend can be small as a point at 5.3 can map to a 0.3 for example and the repetition should not be visible on a real mesh (in opposite to a plane fe). and i could use the same 3d texture for all different ships and stations of a faction. but the advantage is that they don't need to be uv unwrapped and hand painted and all ships + stations of a faction appear with the same pattern but still different. when time comes i will give it a try.

thanks for the explanation. i had something in mind in this direction.

 

Just bought your plugin. Very very good work! I quickly tested it in a lowly iPhone 4 and it seems I'll be able to generate textures at runtime to use in my game .

I'm having some issues with the editor in Unity 4.6b7 (clipping issues, can't set colors in gradient, etc). Do you have access to the beta so that you can test it?

Cheers,
Alex

 

@Game Whiz: I don't have access to the beta. Where is the problem situated? Are you unable to summon the gradient popup via the properties panel, or does the gradient popup itself not work as it should?

Oh and here's an example of combining noises for a terrain material base, in response to your private message.

 

The gradient popup appears but it's clipped, and because of that I can't choose colors. I've reverted back to 4.3.4 for now.

 

@Game Whiz: The gradient popup is a Unity control - like the curve popup - and not under my control. I'd expect the same problem everywhere gradients are used, making it a Unity 4.6 bug worth reporting. Could you check that?