World Machine Community

News and Development => Feature Requests => Topic started by: EhrenFasser on October 13, 2011, 03:42:38 PM

Title: GPGPU enhancments/Multiscreen
Post by: EhrenFasser on October 13, 2011, 03:42:38 PM
WM already does a nice job using multiple cores efficiently - but what would really bring things to the next level would be adding in support for, and taking full advantage of, GPGPU's via OpenCL. The program is already heavily threaded so extending than onto the GPU should not offer any major challenges as far as the core architecture is concerned.

The performance increase alone would bump this up to being the best world generation package on the market, period. Depending on how well it scales the preview window could be the actual finished output, which brings me to my next wish: Proper multi-screen support/GUI optimization.

It would be great if the GUI elements were able to dock/detach/move while allowing view adjustments in the output panels. I am picturing having one screen with the device layouts and device settings/options with the second screen having the 2d/world/3d/layout screens up. Changes on the device screen propagate to all views instantly during building and tweaking. What really bugs me right now is being forced into using that tiny preview postage stamp while I am tweaking settings - and what really bugs me is not being able to manipulate the preview at all until I am done tweaking.

If proper OpenCL support gets added  the program could speed up by a factor 50 or more and if the GUI is fully decoupled and allows multitasking inside of it - iteration times are going to plummet while quality of finished works will increase. I hit a wall right now where something becomes 'good enough' because making the tiny adjustments needed to keep improving quality begin to take more and more time to get an accurate visualization result on - never mind rendering out final quality assets. World Machine is great because you have the tools you need to pick all the low hanging fruit in next to no time at all - but each notch up in quality after that takes an order of magnitude more time to complete until you arrive at a point where continued tweaking becomes a practical impossibility. I have had worlds take 20 hours to render out at 512x512 quality with the final 8K renders taking about a week to get done.

I am willing to contribute code towards these goals. I have contributed extensive amounts of code to the BONIC CUDA port and I work in automotive industry as a lead programmer on a proprietary CFD simulation package - 600k+ lines of code targeted at Nvidia Tesla hardware via CUDA. I know OpenCL and CUDA inside and out. I never bothered with firestream and don't care to since AMD can't write a driver worth a whiff.

So in summation: OpenCL and a proper multi monitor GUI.
Title: Re: GPGPU enhancments/Multiscreen
Post by: OlaHaldor on April 30, 2014, 12:10:28 AM
I second this request for OpenCL processing, to cover most of modern cards from either AMD or nVidia. It would mean a lot to get builds done faster. More creativity, more room for testing things, make mistakes and fix them faster than before.
Title: Re: GPGPU enhancments/Multiscreen
Post by: Demostenes on June 10, 2015, 07:07:39 AM
+1 for this  :D
Title: Re: GPGPU enhancments/Multiscreen
Post by: ozdeadmeat on July 16, 2015, 05:05:51 AM
Title: Re: GPGPU enhancments/Multiscreen
Post by: Cubik on July 18, 2015, 05:26:55 PM
At this point I would take a complete feature freeze for a year or more if it meant making WM gpu compatible.  The lack of speed has really capped my productivity. 
Title: Re: GPGPU enhancments/Multiscreen
Post by: Kivak on July 20, 2015, 04:00:00 PM
+1 for GPU
Title: Re: GPGPU enhancments/Multiscreen
Post by: ilbiffi on July 20, 2015, 11:34:09 PM
+1 for GPU
Memory also is an issue for my needs, there's some builds that would require 2tb of ram to produce so I had to remove tons of features. If the application could be clustered in an hpc environment that would be cool as well.
By the way I'm not sure how Stephen works (I think he's alone) but I'd be happy to fund him on kickstarter or elsewhere if this could help him hire other people.
Title: Re: GPGPU enhancments/Multiscreen
Post by: Blia on September 26, 2015, 02:59:58 PM
+1000 for GPU rendering !

For such software (World Machine), it makes sense to support it.
It's almost surprising that it doesn't support it yet.
Title: Re: GPGPU enhancments/Multiscreen
Post by: Demostenes on February 19, 2017, 08:30:07 AM
I think this is more and more actual. This project shows, that it is perfectly possible and that it tremendously increases productivity, because you can iterate 1000x faster (even in real time):

WM has best erosion filters and flexibility by far, but this is something, which will be game changer. I would accept feature freeze for any time time period in exchange for GPU support, because iterating is now very slow, especially with more complex projects.
Title: Re: GPGPU enhancments/Multiscreen
Post by: Someone on February 19, 2017, 04:08:04 PM
Weather or not World Machine has the best erosion by far is quite debatable. Compare to real world examples and compare World Creator To World Machine and it is not merely a matter of opinion but more what looks the most realistic to the real world. What World Machine lacks is many levels of differing types of erosion, specialized types of sedimentation, more natural looking organic fluvial types of erosion, usually World Machine can be guilty of looking more angular is certain areas or just less natural. If you have traveled enough and looked at enough photographs and text books then the eye can pick these things up. There are still areas that need to be addressed like Alluvial, true more accurate Talus, better depositions, new ways of displaying sediment distribution.
Title: Re: GPGPU enhancments/Multiscreen
Post by: jgwinner on May 31, 2017, 07:31:50 AM
GPU Erosion could be added via the plugin's I think.

Would people pay for that?

I've wanted to write a wind carving node, a sand carving node, and a continental erosion (including subduction, that kind of stuff).

I've also wanted to write a small scale erosion node that did a good job of eroding around fixed objects; I've done it with nodes, but it's tough. Basically, if you had say a set of stairs, you'd want to erode the 'edges' of the stairs so mud would flow down them, but not actually cut into the stairs. You can't really do it with hardness maps as the entire stair is 'hard'. Sediment would flow down it, but not cut into the surface.

== John ==