So, I finally got around to playing with the Code Device and started working on a Whittaker Diagram device (with added altitude) for Biome placement based on Temperature, Humidity, and Altitude. I must say… this is my favorite device now!
This is not perfect (I literally started learning it today, and this was more of a project to learn Parameters, Inputs, and communication between the Host and the Compute/Kernel)
Well now. Thank you for prompting my next research project! I’ve got to learn about all of that!
Got the Bitmap Output figured out, and now Channel Encoded each element (Temperature (R), Precipitation (B), and Influence over Temperature (Soon to add Precipitation to this as well)). Altitude was separated from the others in terms of direct representation in favor of influencing Temperature and Precipitation. This seems to work better as an influencer in regards to the other 2 because it allows more granular adjustment to control, for example, colder temperatures higher on mountains. Allowing it to impact Precipitation will allow enforcing snowy regions within the colder regions, as well.
The plan is to output the processed Altitude map as a Heightfield as well.
Splitting them into channels also prevents the weird scenario with Greyscale where:
Temperature 1, Precipitation 0
and
Temperature 0, Precipitation 1
result in the same biome (Which would not make sense).
Red makes sense for Temperature, and Blue makes sense for Precipitation. Just some nice correlations, haha. General rule is, “Higher Blue means Higher Precipitation. Lower Blue means Lower Precipitation. Higher Red means Higher Temperature. Lower Red means Lower Precipitation. Brighrer Pink is Higher Both. Darker Grey is Lower Both.”
Also of note, using the Altitude Map as an input into the Displacement Angle port makes it try to follow the terrain heightmap to some extent.
This device is exciting! @Stephen, is there any chance to get dynamic inputs and outputs (As in, the number of inputs/outputs so the number of Zones can be dynamically output as well. For Inputs, this could allow passing textures in for each so it can output a material map or something), as well as the ability to compile the device into a custom device that shows up in the Device Listing (Under the header of our choosing)? Would be awesome to be able to create devices that integrate directly!
Glad you’re having fun with it! The Code device is still very alpha, but obviously the potential is immense.
The goal is to eventually expose almost everything a native plugin can do to the host script. That could certainly include dynamic # of ports
Some of the specific future improvements will include from this list:
Another idea would be to allow adding parameters, inputs, and outputs just through code (Rather than through the UI). Changing those can be a hassle as it needs to be changed in multiple places, and the UI gets cluttered fast with names and IDs. I am also dreading creating a device that requires a lot of any of them (Parameters stand out to me as potentially becoming the worst, though).
Either that or a reworking of the UI for them (I think it being a sidebar enables a lot of the issues with clutter), including dragging and dropping for order (Rather than index changing, as that can get interesting with larger lists, too)
This device is most likely going to be a focus of mine, as it basically caters to everything I have wanted in an application like this. Just throwing my thoughts out there while it is in Alpha state, haha.
Code Device: Rain Shadow Select
This one takes in a heightfield and lets you choose cloud height (Determines heightmap blocking), Wind Direction (Direction of the Rain Shadows), and Wind Strength (How far the Rain Shadow selection goes). The plan would be to allow “Wind Direction” and “Wind Strength” heightfield inputs as optional inputs that would allow you to granularly control them both as well as a “Cloud Density Mask” to impact where it occurs. The idea here is to refine the Whittaker Device and turn this into more of a “Precipitation Mask” generator that would get fed into the Whittaker Device to generate more realistic terrains with ease.
I want to build in distance tapering and some smoothing into this, as well as incorporate a few more outputs (binary output (0 or 1) and Area Output (Distance based, not heightmap based)), whether that be explicit outputs or adjustment based.
This one was for me to play around with efficient looping (Indexing efficiently) and utilizing the distance and elevation parameter types as well as bounds checking. I am pretty happy with how it came out.
Updated. As a selector, it makes more sense not to be based on the heights. I also added the distance falloff and excluded the areas above the cloud height. The best solution would be to include the areas above the height on the blocked side of heights above the blocking height. I have a solution to that, but I am taking a short break, haha.
It now it includes the areas above the height on the blocked side of heights above the blocking height (That was a mouthful!). There is room for optimization, but it runs great in the current form. That said, I really like optimization, so that will become a thing!
Oh, and it inverts the direction for calculation so the rain shadow direction matches the direction parameter in the parameters list.
Quick mockup using the Rain Shadow Device. This also uses the “placement input” for some distortion (Make it look less static).
@Stephen I noticed wm.mask() does not seem to function to get the mask input (Always gives me “nil”, even when connected). Is this feature implemented? It is referenced in the documentation, but there is no note on whether it should work or not.
Whoops - it looks like the mask was implemented but never plumbed through to LUA.
Update:
That’s right - the mask input is waiting to be finished at the same time as the spatial parameters, as it requires similar plumbing in terms of supplying a default image if no override is present. It will not be 4045, but hopefully sometime shortly after.
