Done at last:
Introducing DynamicAnimControl - #17 by sgold
I finally implemented tri-planar mapping into my PBR terrain shader, and also into my decal system
I also started a new map with a āShiney Gem & Crystalsā theme that Iām going to work on as I work on improving my PBR terrain - this way I can have a map with lots of shiny textures where the indirect lighting stands out more.
Iāve been doing lots of thinking about how Iād like to improve the PBR terrain- I definitely want to make an updated version that uses a texture atlas and support more than just a normal mapā¦
but more importantly Iām thinking of creating a small āTerrain Utilityā library and implementing it into the SDK if possible⦠that way you could finally set the Roughess/Metallic/AO map conveniently from the terrain editor. And Iād also like to upgrade some other features to the terrain editor⦠One thing that I would really like to do is extend the Texture Painter brush so that it can use a noise value along the edges so the terrain textures blend together more naturally.
Or maybe you want to put it in form of an standalone JME AppState with a bunch of Lemur GUI stuff so one can attach it and use it in game.
Sdkās terrain editor could definitely do with some love. However, I donāt think itās a good idea to do it before we get a standard terrain pbr shader into the engine itself. So might want to start there.
That could be a better idea to start with, especially since thereās no standard PBR terrain yet.
Yes thatās a good point. Maybe it could be a good idea if I start a thread sometime soon, and then we could discuss the details of how the standard PBR shader should be.
Derailing the thread a little, but triplanar on PBR is quite expensive. The workaround would be to pack as many textures into a single input as possible. This most likely goes against the standard workflow, so a converter of sorts would have to be supplied - and a writer for the final output so it doesnāt have to go through the same routine every time.
That is to say that you give it the materials (roughness, metallic, AO) or whatever, and pack it into a single texture rather than sampling a million textures 3 times. It would make the shader code a lot simpler, too.
That doesnāt mean you canāt experiment with it in your own fork though. Especially since you shouldnāt have to change much for it to work
That is true Iāll have to keep that in mind when I add the metallic/roughness/ao/ any other maps.
I hadnāt thought of that yet, since the simple PBR terrain im using now only has enough room for normal maps, and just uses float values for roughness and metallic, since Iāve already hit the 16 texture limit with just Albedo and Normal maps
It sounds like that could be a good way to keep it to 3 texture reads per texture slot: Albedo map, Normal Map (packed with parallax in alpha channel), and a āMetallicRoughnessAoā map packed in one.
I like this idea as well:
Iāll give this a try soon when I have some time and see if i can make any progress - Iāve always wanted to extend the terrain editor more but havenāt quite had the skills with the terrain and its shaders to do so until lately.
I definitely am going to try to implement a Noise Brush straight into the terrain editor as soon as I have some time and can figure that out.
I decided to start working on an AppState utility for integrating a PBR terrain- starting with the converter for packing AO/Roughness/Meatllic maps, since the idea was fresh in my head (and it can also work for packing the Metallic and Roughness maps that the normal PBR shader uses)
My GUI layout is really messy, but it was amazing how quick I could throw this together with Lemur in a single class, compared to the extra setup I would have needed to put in for a nifty menu.
working towards an Into the Spider-verse Shader, from :
to
you might be able to spot:
- Sobel lines
- Polerization
- Halftones
- Hatching
- Toon Edges
My PC is still dead, so can only do limited projects on this POS laptop =(
Into thetoucher-verse.
Being in thetoucher-verse is like floating on a cloud, except you are being eternally assaulted by a sea of thousands and thousands of hands coming at from all directions. An ethereal flesh-light of hands, and you are the dong.
I canāt work out if thatās good or bad, or good then bad. Do they let you go to sleep in peace afterward or do you have to have the obligatory yet polite/respectful chat first? Do you want to have the chat? What if you like one more than the other? So many questions.
They are hands, all they do is touch, for-ev-er, no sleep, no peace, eternal touching⦠living the dream.
And now we know why your avatar is blue.
and we also know why spiderman hands are so big.
No screenshot, but still kinda cool WIP with annotations. I needed a better way to edit shader values at runtimeā¦
Before I was use Swing for my fx configuration, and was writing a UI class for each of my filters, that is full of the Swing interface and links to filter set methods. Quite cumbersome and too much of a pain to use during development, perhaps just because Iām lazy.
Now Iāve added custom annotations to use with each a filterās fields, such as:
@TTFxUIMapper(
title="Max Shape Size",
displayType=TTFxUIMapper.DisplayType.SLIDER,
maxValue=2f
)
private float shapeMax = 1.0f;
the Swing UI uses that info to generate itself, and automatically map its values to the filters setters. Sooo much cleaner, has reduced hundreds of lines of gui code to a few generic methods and some annotations. Shader dev time /= 10, truely.
Additional Benefit: The annotations are not coupled with Swing, if and when I finish my Lemur skin, I just need to adapt the code that generates the different Swing inputs, to generate the Lemur equivalent. Or an HTML interface for whatever reason.
tl;dr annotations = rapid shader dev
Just being able to adjust shadow / mid-tone / highlight clipping values in real-time, and displaying debug output yields cool results ā¦
I would never have stumbled across this without a real-time interface.
I can now tune the shader to mimic the ānormā Spider-verse effect of halftone highlights, line hatched shadows. Usecase check.
There is some ugly blockiness from the down-sampling. The halftones are full opacity, on top of the image, some subtly here will go a long way.
Changing max shape size of the shadows adjust how thick and how tapered the hatch lines are.
To make this work I needed to create 2 additional render passes, one for the color information, and one for the lighting information, however the latter could simply be derived from the scene texture.