Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3]
  ignore  |  Print  
  Simplex noise, experiments towards procedural generation  (Read 21787 times)
0 Members and 1 Guest are viewing this topic.
Offline Best Username Ever

Junior Member





« Reply #60 - Posted 2012-12-04 22:58:11 »

Quote
I mean each frame everything needs to get recomputed, how can this be fast?

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.
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #61 - Posted 2012-12-05 10:36:26 »

Quote
I mean each frame everything needs to get recomputed, how can this be fast?

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.

Oke, that makes it clear Smiley.
So calculating static (not frequently changing) noise on the cpu would still be faster.
Offline Roquen
« Reply #62 - Posted 2012-12-05 10:50:57 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #63 - Posted 2012-12-05 11:22:45 »

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).
Offline Roquen
« Reply #64 - Posted 2012-12-05 11:44:10 »

Not if the data is for the GPU...render to texture.
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #65 - Posted 2012-12-05 14:31:44 »

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)
Offline Roquen
« Reply #66 - Posted 2012-12-05 14:56:56 »

No, the GPU is directly writing to VRAM.
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #67 - Posted 2012-12-05 15:09:25 »

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?
Offline Roquen
« Reply #68 - Posted 2012-12-05 15:33:48 »

Yes indeed, hence "render to texture" mentioned previously. Smiley
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #69 - Posted 2012-12-05 15:40:32 »

Yes indeed, hence "render to texture" mentioned previously. Smiley

But how, i dont see how this can be done on the gpu.
How is this done?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline davedes
« Reply #70 - Posted 2012-12-05 16:53:02 »

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.
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?
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.

Offline Roquen
« Reply #71 - Posted 2012-12-05 18:08:27 »

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.
If the destination is on the GPU, doesn't it make more sense not to use the CPU?
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.
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #72 - Posted 2012-12-05 18:32:39 »

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.
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?
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.

Thank you, i was fishing around for an answer like this.
I didnt know this was possible, thanks Cheesy
Offline cheatsguy

Junior Member


Medals: 3


Gamer turned Pixel Artist turned Programmer


« Reply #73 - Posted 2012-12-05 19:20:46 »

I would love to see a terrain generator made from this. Nice work!

Busy between school, work, life, games, programming and general screwing around.
If you'd like some pixel art for your game, send me a PM, i'll see what I can do.
Current project: http://elementalwarblog.wordpress.com/
Offline philfrei
« Reply #74 - Posted 2013-02-25 22:49:24 »



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.


"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Offline philfrei
« Reply #75 - Posted 2013-04-09 21:41:39 »

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.

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?
[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.

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Pages: 1 2 [3]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (22 views)
2014-09-19 03:14:18

Dwinin (35 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (87 views)
2014-09-10 06:39:09

Tekkerue (42 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (47 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!