Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
The name of this software is World Machine. What is the first (bolded) word in the name?:
New York is a major city in America. Type the initials of the city as the answer:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Takulas
« on: November 23, 2013, 08:45:24 AM »

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.

Posted by: Stephen
« on: November 22, 2013, 05:29:10 PM »

Takulas:

In 2.3's tiled export dialog, you can specify any combination of tiles to export only a subset of the existing tileset; so if you're making changes only to a certain area, you can re-export only that area and it should just seamlessly drop into place.

For changes that might spill out of your work area, I would recommend using the Tiled File Input to re-load your tileset and then apply changes to it; unaffected areas should roundtrip with no issues, and this way you are 100% assured of things blending properly.

Regarding multires, I originally was looking at having devices to change the resolution exactly as you mention; but it ended up feeling like a lot of busywork to set resolutions. The current modes are not complete either; eventually I plan to allow you to set resolution by-group as well, which is an extremely handy shortcut.
Posted by: Takulas
« on: November 19, 2013, 04:07:35 AM »

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.
Posted by: Ben
« on: November 19, 2013, 01:19:57 AM »

Quote from: Remnant on November 18, 2013, 02:00:39 PM
I want 1cm per pixel detail, and my overview section is 100km of terrain. Oops.

Yeah I can see how that might be an issue. :P Perhaps it could have some min/max safety built in. It's something I've had issues with several times in the past, the disconnect of scales between multiple render extents that is. But I'm getting better at managing it.

Quote from: Remnant on November 18, 2013, 02:00:39 PM
Can you explain more of your use case on the lookup device in Filter forge?

Certainly! Attached is a simple example of why I love lookup and want it for WM. It's great for making impact craters, which is probably the most obvious example for WM use. You can generate a flow map and then use that as coord lookup for a noise. It can also work as a more powerful version of displacement (because it's 2d). Angular gradient would be a required addition to the Radial Grad device if Lookup were to make it in. See the most bottom device in the attached image for what I mean by Angular gradient.

I'm still not sure what kind of issues these coordinate warping devices would cause in an LDR environment. Are there any plans to start supporting some HDR so we can have gradients that go beyond 0 and 1 to allow them to be used as coordinate lookups? FF was LDR for a while and has done a decent job bringing in HDR without having to overhaul all at once.

Edit: Forgot to mention, as you can see in the image, it's especially useful to work on the look of my noise/pattern in a non radial environment and then apply the radial coords after. Also something else to note is that curves are their own distinct device type, which is GREAT! I can make 1 curve and supply it to as many tone curves as I want, which I didn't do in this example lol.
Posted by: Stephen
« on: November 18, 2013, 02:00:39 PM »

Hi Ben,

Yes, that is a good point with regards to relative to world extents; but other options seem fraught with difficulty. Resolution by detail scale is an interesting idea, but it would have to be used carefully to keep things from blowing up when scaling (I want 1cm per pixel detail, and my overview section is 100km of terrain. Oops.)

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?
Posted by: Ben
« on: November 18, 2013, 01:46:25 PM »

Any thoughts on providing another device resolution option for setting scale by Detail Scale (m/pixel)?

The problem I have is "relative to world" is actually "relative to current world extent," so if I have multiple Extents that result in a different m/pixel detail scale, then the per device resolutions wont match up.

In general I wish coords were more robust in WM. For example, when building shaders in UE3 I can supply all kinds of interesting coordinates like world, local or make my own based off noises, UV gradients, dot products etc. In Filter Forge I can use a Lookup device with x,y coords, which is essentially the same but better. If Lookup could be made for WM I would be so happy, it's one of my most used/powerful tools in FF. It's the kind of feature that might require introducing HDR to WM though so maybe it's too much for right now.
Posted by: Takulas
« on: November 11, 2013, 08:18:17 AM »

never mind, finally found it. :)
Posted by: Stephen
« on: November 08, 2013, 02:20:37 PM »

Yes, I just found the group-bug with macros myself. This is a simple oversight bug, but its fairly important as it is permanently changing any groups you may have inside your macros. I am going to try to push out a bugfix quickly to address this.
Posted by: Ben
« on: November 08, 2013, 01:34:54 PM »

Found another! Suddenly all my macros contain duplicates of all the comment boxes in my top-level graph. Any new macro I add will inherit the comment boxes from the top level. Moving a top-level comment box position doesn't cause the ones in the macros to update position, so they seemed like a copy rather than instance at first. But then I went to add a 2nd layer of macro (macro within macro) to see if it would inherit from top-level or just one level up. The moment I added the new macro it updated the positions of all comment boxes to the top-level positions, so they are instances that just aren't updating until a macro add/delete. This is the case with the 2nd level macro comment boxes too.
Posted by: Ben
« on: November 08, 2013, 12:32:09 AM »

Such a great day! :D

First issue I have is that when I have a down sampled branch going into a macro, it isn't passing along the down sample info/message to the following nodes within. I assume they're operating at the down sampled resolution, correct?

The R hotkey for Set Device Resolution doesn't seem to do anything right now.

When I specified a file name for a Library output, I didn't add the .tml to the name which caused the path to get saved with no extension, other output devices auto fill the extensions.

So far it seems quite stable!

Posted by: motorsep
« on: November 07, 2013, 10:28:22 AM »

Is it about LOD iterations for the terrain mesh output?
Posted by: Stephen
« on: November 06, 2013, 09:33:19 PM »

Here's a ready-made thread for you to chime in with your thoughts and ideas about the initial implementation of this feature.

It should work and has been tested against both normal and tiled builds. The only gotcha is that the resolutions reported in the UI will not be right, as the tiled build resolution is different from the world resolution. I'm thinking about adding a toggle to display normal or tiled res in the device net.