[quote]I mean each frame everything needs to get recomputed, how can this be fast?
[/quote]
Same with respect to that question. It’s also the “same” for Java (or any programming language) as well and even for non-noise or non-graphics related problems. It’s a time/memory trade off, not something inherent to OpenGL. The texture thing is merely a counter-example to the premise of the question. However, if the problem requires you to recalculate every frame anyway, then that’s unavoidable no matter what you use.
Same with respect to that question. It’s also the “same” for Java (or any programming language) as well and even for non-noise or non-graphics related problems. It’s a time/memory trade off, not something inherent to OpenGL. The texture thing is merely a counter-example to the premise of the question. However, if the problem requires you to recalculate every frame anyway, then that’s unavoidable no matter what you use.
[/quote]
Oke, that makes it clear :).
So calculating static (not frequently changing) noise on the cpu would still be faster.
There is no clear-cut answer here. Noise is a massively parallel computation…so the raw speed will be much faster on the GPU. If the destination of the data is the GPU, go with GPU computation if speed is a concern. Otherwise, well…it depends.
But if some sample takes 1000 msec on the cpu and 100 on the gpu, then your still better off using the cpu, because the gpu needs to recreate the noise every frame, while the cpu can store it into memory.
I know that if your rendering some animation with perlin noise, you have to render an new sample each frame, the gpu is better suited for it (within some limits).
Not if the data is for the GPU…render to texture.
“render to texture”
Is’nt that done on the cpu, like i sayd (forgetting about texture id / data send)
No, the GPU is directly writing to VRAM.
That would be really cool.
How would it be possible to render noise with the gpu on an texture?
Yes indeed, hence “render to texture” mentioned previously. 
But how, i dont see how this can be done on the gpu.
How is this done?
[quote]Noise is a massively parallel computation…so the raw speed will be much faster on the GPU. If the destination of the data is the GPU, go with GPU computation if speed is a concern.
[/quote]
If the destination is on the GPU, doesn’t it make more sense not to use the CPU?
[quote]But how, i dont see how this can be done on the gpu.
How is this done?
[/quote]
Use a shader and FBO. Bind the FBO, render a quad with the noise shader in use, then unbind the FBO and shader. Then you can render the FBO color texture to the screen as much as you’d like without enabling the noise shader.
In other words: you’re calculating the noise only as necessary (as with the CPU implementation), but you are doing so without any texture transfer (CPU -> GPU) and also using the much more powerful parallel processing of the GPU.
If there are certain tables/constants that do not need to be calculated every frame, you can upload the data to a texture and sample it in your noise shader.
If the destination is on the GPU, doesn’t it make more sense not to use the CPU?
[/quote]
Yes, if the consumer is the GPU, then the GPU is the ideal producer. However it might make sense to use the CPU for other reasons…most notably engineering time if you have a working CPU version and speed isn’t a concern.
If the destination is on the GPU, doesn’t it make more sense not to use the CPU?
[quote]But how, i dont see how this can be done on the gpu.
How is this done?
[/quote]
Use a shader and FBO. Bind the FBO, render a quad with the noise shader in use, then unbind the FBO and shader. Then you can render the FBO color texture to the screen as much as you’d like without enabling the noise shader.
In other words: you’re calculating the noise only as necessary (as with the CPU implementation), but you are doing so without any texture transfer (CPU -> GPU) and also using the much more powerful parallel processing of the GPU.
If there are certain tables/constants that do not need to be calculated every frame, you can upload the data to a texture and sample it in your noise shader.
[/quote]
Thank you, i was fishing around for an answer like this.
I didnt know this was possible, thanks 
I would love to see a terrain generator made from this. Nice work!
http://hexara.com/Images/candelabraBIG.JPG
This graphic can NOT be done with the currently linked .jar. I want to clean up some aspects prior to posting the applet.
The project underwent a major “functional programming” makeover. Major thanks to LoomWeaver for getting this going, coding and providing guidance. The graphic is an example of what the new version can do. UI is much improved…am looking forward to showing off the latest version (hopefully by end of week).
@cheatsguy – Terrain generation in some form may be possible. What are you looking for in terms of output? Arrays of data or buffered images or what? The tool is not set up so much for 3D though.
I’ve just posted a big revision of the Simplex noise 2D texture editor.
http://www.hexara.com/SimplexBuilder.html
(Link is also on first post)
The interface is a lot better than it was, but there’s always room for improvement, and the code is more “functionally” written. I’m hoping it now provides a better foundation for collaboration.
The GitHub project name is “SiVi”. Is that enough to locate and join in? I am a GitHub newbie.
There is a nice long “issues” wish list.
[s]But to start, I need to fix the “settings panel” which crashes in the applet form. It allows (when it works) you to specify the size of the graphic and the number of octaves. The tutorial works as a separate window, so the Settings window should be able to do so too. But my specifying “on top” seems to be causing problems. Or maybe it should just be a submenu.
I wonder if the gradient or colorbar editing windows work…dang. Bloody hell.
AccessControlException: access denied (“java.awt.AWTPermission” “setWindowAlwaysOnTop”)
Any suggested quick fixes for this?[/s] [Edit: made the various submenus modal and took off the “alwaysOnTop” setting, for now.]
The tutorial is going to be rewritten. But you CAN page through it and click on the top graphic to bring it into the editor as a template.
improvements:
Specify size of graphic.
Specify number of octaves.
Drag & drop color maps (helps if you want to tinker with the mapping, to have copies).
Specify three gradient types to be “modulated” by the noise.
To recap: the point of the tool is to be able to try out and tinker with Simplex noise settings. Much easier to do it with this interface than by rewriting code. The settings will then be transferable to code (either via provided templates, or via code-generation).
Hah! From last post, I said one week, and it took two months. A programmer friend of mine says make an estimate, double it, then go to the next level of units. He was right this time.