Noise Function Nodes?

[agentfx]

Most people here probably use a 3d package. All have built in noises, perlin, etc, why does UDK not have any noise nodes? A few places I've worked friends have written their own noise nodes (mostly for houdini) so it can't be that its a difficult thing program.
I was surprised not to see them in UDK, and to see people using tileable noises instead. Is it that much of a calculation hit? Or am I just missing them somewhere?

[elmuerte]

Why waste computing power on creating noise when you can a similar looking effect with a few textures and shaders?

[agentfx]

true, noises can be used for a number of things, but I suppose all those things can be made with noise textures also. The nice thing to have them made procedurally is that you can edited them in real time to get the amount of noise frequency amplitude, etc, with only one node, vs the number of nodes needed to edited a texture that's not quite right.
Its convenience I suppose, but a big convenience. Do you think it would really be that much of a computational hit? It could conceivably replace, textureCoordinates, Panner, a multiply & constant, power, some duplications of itself, and all the other nodes that we use to edit noise textures.

I imagine it must still not be worth the computing power, since the code isn't that crazy
http://www.flipcode.com/archives/Per...se_Class.shtml
I'm just thinking that it should be more efficient to make a procedural noise node that can be optimized for the game.

[Nawrot]

I do not have any source for random number generator done in GPU code, but this code for x86 will give you idea about difference in code length.

For creating one random number (uniform distribution, integer etc) something like you want for static noise:

	  mov	 ax,seed1
	  mov	 bx,seed2	       ;load seeds
	  mov	 cx,ax		       ;save seed
	  mul	 constant	       ;(dx,ax) = ax * constant
	  shl	 cx,1
	  shl	 cx,1
	  shl	 cx,1
	  add	 ch,cl
	  add	 dx,cx
	  add	 dx,bx
	  shl	 bx,1		       ;begin scramble algorithm
	  shl	 bx,1
	  add	 dx,bx
	  add	 dh,bl
	  mov	 cl,5
	  shl	 bx,cl
	  add	 ax,1
	  adc	 dx,0
	  mov	 seed1,ax
	  mov	 seed2,dx	       ;save results as the new seeds
	  pop	 bx		       ;get back range value
	  xor	 ax,ax		       ;clear register
	  xchg	 ax,dx		       ;adjust ordering
	  div	 bx		       ;ax = trunc((dx,ax) / bx), dx = (r)
	  xchg	 ax,dx		       ;return remainder as the random number

Now something similar to 2 values that you multiply:

        mov eax,value1
        mov ebx,value2
        mul ebx

Note that code is only to show difference between needed calculations, not actual code for shaders. And it is for x86 CPU, but proportions stays same for GPU.

[agentfx]

I see what you're saying but it doesn't have to even have random in it. 2 sin waves overlapping at different frequencies creates a noise. rotate their UV to be different you get even better noise. We already have sin waves (as an example not really what I dream of)
Does perlin have random numbers? I don't know but it has patterns in it so I would be surprised to see how often random needs to be calculated.
There already is random number generators built into UDK, particle systems use it all the time it can't be the costs there.

Altho, yet again, I have to admit I probably know enough to think I know what I'm talking about but don't... at least I know that? lol.

[Nawrot]

Random number generator that is used for particles is way too slow for shaders and materials.

You are thinking about procedural texture system like FilterForge or allegorithmic. Such things are too slow for shaders, they may be done for generating textures before level starts. But it is lots of coding for almost no real gain, such textures can be created in external app, then imported. And tiling patterns can be hidden in many ways.

[iniside]

Why waste computing power on creating noise when you can a similar looking effect with a few textures and shaders?

Very simple answer. Because there is limited amount of texture you can use. Also loading textures and managing them is not always faster than generating them procedurally.

[agentfx]

thanks I think I get it now. Yeah tiling isn't the issue. I think its just getting my mind around the constraints of game engines vs pre-rendered workflows.
I still it would be possible to make a realtime working noise node, one way or another, but as you pointed out its obviously not as simple as just reproducing code that works in Maya.

For normal shader use, I can see your point of "no real gain" but for FX (what I do) I think its different. If for nothing else than blocking in noise type/freq/amp/thesh/ratio combination quickly. That is something in fx we tweak a lot to get the right size to scale.

[3dimentia]

being an effects artist, I feel ya, however I feel that textures makes more sense. Bring in some base simple textures like perlin, simple noise, etc etc and then modify them with the shader tools as needed. You can get away with most everything you need this way.

There is a reason why most engines don't/won't do realtime prcedural noise. It is too slow for realtime. You would have far too many permutations needed to make it useful for realtime, and a similar effect can be done faster and simpler with just a texture call.

I've known about the sine wave noise for a while now, and I can tell you, I haven't found a need for it, short of static on a screen.

Good luck!

[agentfx]

thanks for the insight. I guess you're right... probably just need to make my library of noises and alphas that I would normally make procedurally .