• Welcome to World Machine Community. Please login or sign up.
July 20, 2019, 03:08:46 am


Read the Development Diary for an inside look at World Machine's progress!

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Takulas

Development News / Re: 3.0.dev1 Released
August 19, 2014, 03:45:53 am
Quote from: Hotshot on August 19, 2014, 03:02:02 am
Where can I grab the 3.0dev1?

You need to make the payment for the 1 year maintenance and it`ll be available for download in your regular download page.

I`m glad I was wrong regarding the subscription. I totally dislike the subscription model. Especially the very rigid mandatory money grabber ones.
Your "Annual Maintenance" approach is a very well thought model. As a customer I`m more than happy to pay this way for your awesome piece of software. It`ll make future safer, for me as a customer and for you as a developer.

One question though: lets say next year August 15, when my recently payed maintenance will expire, a new WM4.0dev1 will be available for me to download. The final release for WM4.0 will come out in October and I didn`t renew my subscription. Will I have the right to get the final WM4.0? Or I will get the final release for WM4.0 only after I payed for my second 2015-16 maintenance? I think I know the answer, but I thought it doesn`t hurt to ask.

And thanks for this great release!
Development News / Re: 3.0.dev1 Feature list
August 18, 2014, 05:32:54 am
Com'on Remnant, it`s Monday.
People are getting nervous!  :lol: :lol: :lol:

On a more serious note, this is going to be a great release.
And somehow, I have a feeling the upgrade to 3.0 it`s going to be as a subscription.
I`m really curious about that.
Am I wrong?
Feature Requests / A few random features request
August 11, 2014, 05:57:18 am
A few weeks ago I decided to dive a bit deeper in the Macros creation science. While working and learning I found myself thinking about some features that will make my life a bit easier, I think.
They might not be that great as I think, but anyway, here they are:

1. ROUTER&DISABLE device- will switch and disable at run-time all the devices that are not supplied with data. I see them very similar with the Router device but this device will not only feed the data to only one output, it will also disable at run-time all the other devices that are not supplied with data. The main difference I see is that this device will also disable any generators you have in the network that are linked to the non-feeded ports. This will totally prevent using memory if the devices are not used in the final settings of the Macro.
2. Macros in Macro - We can place macros inside macros and redirect the parameters to the main (parent) Macro. My request is to have the option to also be able to pass upwards the presets from the child/incorporated Macros.
3. The possibility to add longer names for devices and Macro input&output parameters
4. STICKY GROUPS - I noticed that devices become sticky when they are placed outside the group and are close enough or touching the group. I think it`ll be useful to have the option to turn on/off the same feature between groups themselves. Being able to glue the groups between themselves can help organizing the flow, I think.
5. Maintain Zooming -  When switching tabs in the Device View it always zooms out. It`ll be good to preserve the zoom and position of the view-port when changing tabs in the WM interface.
6. TABS in the Macro main UI. Having tabs in the Macro interface will help to organize the Macro. I can choose the first tab to deal with erosion maybe, the second one with colors and the third one with miscellaneous settings. I was thinking that having one Macro Parameters device for each tab will make things easier to organize the connections inside the Macro. Naming the Macro parameters device will automatically name the Tab inside the Macro UI. This will also help quite a lot in the case of having Macros with many settings (parameters). No matter how they look, like the main tabs in the WM interface, or like the Bank Selector device, as long as you can customize each of them individually.
7. Bank Selector for Integers. Having such a device will give me the option to set different values for different devices and switch the values for multiple devices at once with only one cursor(parameter). Fast and with a minimal interface.

Thanks in advance for any of the above.


P.S. - On a side note, I`m really eager to see and try the next WM version.   :)
Bug Reports and Help / Re: Delete Groups?
July 28, 2014, 01:44:29 am
Doesn`t work.
WM here.
I suppose it`ll be fixed in future builds. :)
Feature Requests / Advanced Snapshots
March 27, 2014, 12:45:20 pm
I was thinking that it might be really useful (at least for me) to have an advanced snapshots feature. What do I mean with that?

Instead of "Save Viewport As Image" option to have a "Snapshots" option. When I click the "Snapshot" in the menu, a viewport capture will be automatically taken, at the full-detail resolution, without another additional click on the "Full-detail Snapshot" button, into a preselected location. Or this functionality can be implemented to the "Full-detail Snapshot" button itself.

The second nice feature will be to remember and store the camera position in the viewport, and save that as an option in the menu, to the "Snapshots"/"Save viewport as image". Exactly like the "Recent World Files" or "Recent Sessions" menu options. And to save all this snapshots with the scene. If I reopen the scene later, I can continue my work, take a few more snapshots and compare them with the old ones. I can redo the old ones too if I lost them too. And with a keyboard shortcut it`ll be brilliant.

It`ll help me greatly, workflow wise. Would that be possible?
Quote from: signum on February 20, 2014, 09:20:51 am


Good to hear that we can get it soon and nice to know that World Machine has so efficient support.

Quoted for agreement.

Quote from: Remnant on February 21, 2014, 01:19:57 am
good ideas all around.

Every suggestion in this thread has been implemented, and I'm just testing to make sure nothing else got broken as a consequence. If everything looks good the fix + enhancements will be rolled out soon.

Hats off to you, sir!
Would it be possible to add numerical input for the key positions? I think it might help a lot, giving a bit more control not only placing the colors based on altitude, but also building more complex gradients. Having also a scroll list, when the keys are very close positioned, might help also.
Regarding multires, I think it`s quite cool the way it is now. Having group resolution setting option will help indeed.

Regarding the splitter/merger devices I still think it will be useful. I know about custom tiles export options in the "Project Settings/Tiled Build Options" and I used them. I read about your results in On the fly fast lossless compression with lz4 and I was quite happy seeing you decided to implement it in future releases and I couldn`t stopped not to associate it with HDD Cache device possible feature. Now, having  all these features implemented and setting the "Maximum builds at once" option at 1-2 devices you might create huge worlds with a really good memory management, with the condition of course, that after the HDD cache device is passing all the info from the disk to the next device it will free the memory chunk used to bring the data from the disk back in the scene. The general idea it was to use, if necessary, all your available memory for only one device. Splitting the terrain area and merging it back after some more intensive computing operations will definitely help with this workflow too. I know about the merging back possible seams issues, but I think if used correctly (maybe using alphas/gradients?) it might be a great addition.

Quote from: Remnant on November 18, 2013, 02:00:39 pm

In regards to coordinates, there are actually some major improvements that I have planned for the next dev push that run along the same lines as you're discussing -- I am interested in your ideas on them. At a minimum, the ability to easily work in local-space (useful for textures, "hero" terrain elements, etc) including an easy way to place, tile, or scatter such localspace objects into the world. Probably also improved/generalized distortion inputs for all generators.

Can you explain more of your use case on the lookup device in Filter forge?

In regards to coordinates, especially now that multires is in place, I was thinking for a while now to ask if it`ll be possible to have a splitter/tiler device with a possible output for every tile? And having a splitter device will of course require a merger device.
I was thinking that I might want to do more work on the main/hero terrain area and merge back the tiles. Or maybe clone it, move it in a different location use the combiner device and merge it back. It might help a lot in manual tweaking your desired output.
Would that be possible?

Edit: and I have to say I was really surprised the way you implemented multires. I was thinking all the time to a new scale/set resolution device. It looks clean if you ask me, it doesn`t clutter the interface and the general feeling when you look to your devices setup.
never mind, finally found it. :)
Ok, I understand a bit better now. Basically, it`s an compact output storage device.
A few more questions though:
1. Will the new Library" device have an mask input? In case I want to add the stored terrain to the main terrain in my scene and maybe use a Layout device to shape the contour of the "Library" stored terrain for a seamless blending.
2. Regarding the data segregation and memory usage, it will very convenient to load from disk only the data you want (heightmaps, or textures,...etc.), and interface wise, you control that with an specific output you set up the "Library" device. Something similar to the macros inputs/outputs setup. Having organised the Libraries organized as heightmaps, textures, etc., will split your terrains and I find this workflow solution more as a workaround. The main purpose of this device, for me, it is that it gives you the option to store my terrains in a organized and more compact way.
3. It will be nice to have a preview window in the "loading interface" of the Library device. Similar to the Photoshop preview. Or even a main Library presets tab/window for faster preview. this will spare me of rendering separate images for each library device.
4. Will these Library devices use less space on disk, compared to the standard images outputs? I know that different files types have different compression algorithms. Obj files are pretty big compared to an equivalent heightmap.
5. Considering the new multi-resolution feature, will I be able to store a terrain at 1024 pixels size and when I load the 1K stored "Library" device in a new scene, to setup the desired output at, lets say, 2048 pixels? If this option is not possible, maybe a specialized size/scale device will do the job?
Many thanks.
Library I/O sounds really exciting. And considering the other new feature, the muti-resolution support, it looks that the WorldMachine workflow might change quite a bit.
I`m really curious how this new feature will work. And of course, a few questions:
1. You mention that: "The Library I/O devices allow you to store and easily load multiple data packets". Is this some sort of cache file format you use to store built worlds? Or parts of it?
2. How this Load Library device is affecting the memory usage? Using the Load Library device in a second .tmd scene and applying/connecting new erosion devices will change the terrain. After loading the library preset and the data is processed by the newly attached devices, will the memory be discarded?
3. Will I have the option to edit just a tile/chunk from the loaded Library preset? How am I going to do that?
4. Also, will I be able to, maybe, load only the heightfield from the source file, without using memory for the textures I don`t need?

Really curious how the new features will change the way we work now. :)
Many Thanks.

Every time I see a new built (fixes and new features) I get excited (in a good way, of course :) ). I definitively love the way new builds are rolling out.
And reading in the blog section about the new multires way of working in WorldMachine is bringing a huge smile on my face.
Many thanks for your efforts. One of the best spent money on software in the last few years.
Woow, that`s really good news.
This and the Checkpoint/cache device discused in the other thread would make me, and others I`m sure, a very happy world machinist. :D
Definitively looking forward for the announcement.8)
Thanks again.
Feature Requests / Re: HDD Cache device
May 01, 2013, 02:46:52 am
OOhh yeah, having a checkpoint device with these HDD caching features included would be really great. It will indeed enhance workflow and work speed in WM and not to mention the memory management.
Funny enough, I used exactly the Checkpoint device icon for the HDD cache mockup. I thought the best place for such a device would be the 'Flow Control' tab.  :)

Many thanks. :D
Feature Requests / HDD Cache device
April 28, 2013, 03:10:54 pm
Following prior discussions about caching abilities of the already built data on HDD, I was thinking that maybe instead building such a feature in the already existing devices we have in WM 2.3, would be easier to have a dedicated HDD Cache device that will do exactly this: cache the data on HDD.
I`ll try to describe below the way I see such a device working. I don`t know if is possible but I do hope it is.
Instead of saving the session on HDD after working on a scene file I would use a HDD Cache device and I will choose myself the name of the cache file and the location where to write the data. Maybe I can use the same cached data on another scene by loading the data from disk saved in the previous scene because that branch of the device is identical in both scenes. Once the data is cached by the HDD Cache device, if we choose to build the scene again, the devices places upstream the cache device will not be computed, unless we chose to delete the cache from disk in the HDD Cache device window interface. Or if we change the name of the cache file. By changeing the name of the cache data file can be created different versions for a terrain preserving the cache on disk for each version.
That means that the RAM is free of data cached by the HDD Cache device and the very moment  I click on the Build button, the data is loaded from HDD during the scene build process  in memory (RAM), and after it`s used by the next device will be discarded from memory.
I hope my description makes sense and it is possible to build such a device.

Maybe using a poll with some of the feature requests and the things you think might be possible in the next step might help. It`s hard to choose but I would definitively go for bigger worlds, SSD(HDD) devices caching, mostly performance wise improvements. Ans workflow too. But I also wouldn`t mind some nice erosion algorithms.
Anyway. thanks for the final 2.3 release It`s a nice update. I also enjoyed the new examples. It also helps to see how some of the devices are working.
Nice works you have there, QuantumTheory.  8)

Thanks for sharing the scene.
Feature Requests / Device specific/local resolution
March 21, 2013, 08:41:31 am

I noticed that the erosion is resolution dependent, but it happened more than once to enjoy the erosion at smaller resolutions and maybe add detail on top of that. To do that I have to build different scenes, each scene for a specific resolution.
Would it be possible to have an option in the device window/interface to set the render at a different/custom resolution specific only for that device?
I think it`ll give a little more creative freedom and workflow wise it might be more convenient.
Much appreciated, Sir.

One last question. Do you think it will be possible to add as many custom paths we want? Some sort of "+" button to add a new path?
And maybe while we`re here (sorry, it wasn`t the last question) maybe it will be possible to implement a naming convention mechanism.
I was thinking that for every output path, to be able to specify a prefix or a suffix to be added in front/after the base name and after that, if the output are tiles, to append the tiles naming convention.

Again, many thanks.