garageCube

[jasonbeyers]

Feature request: lock aspect ratio button for materials in "render to texture" mode, to produce 1080p output from what would normally be a square.

I've been converting many many ISFs to materials, to gain better control over the shader speed. When using these materials with surface FX, I need to enable texture mode for the materials to work with those FX.

For projects that output a 1080p format (say, a single non-commercial projector), it's easy to map a 1024x1024 material (or higher-resolution square, in texture mode) to a 16:9 quad. However, this poses a performance problem: the unused edges of the texture-rendered material are *still* introducing load on the GPU.

I discovered this in a big way, in a recent project: I was using a very GPU-heaver material shader, and the material version of the shader (in 1920x1920, with sides cut off via input map to give me 1920x1080) was giving me far lower FPS than the original 1920x1080 ISF. I got around this by throwing a direct-rendered version of the material on a 1080p virtual projector window, and routed that to another quad with syphon/spout -- and voila, things were perfectly matched FPS-wise with the original ISF.

I would love to employ this strategy for everything, but that can produce a mess of syphon/spout routing chains & extra surfaces, and those texture-sharing protocols do take up GPU memory.

So, the idea: add a "lock aspect ratio" button for materials, that will become visible when "Render to Texture" is enabled. The button would enforce a 1:1 aspect ratio no matter what the user-defined "Texture Rez" is, allowing users to produce 1080p content from a material without going through any of those syphon/spout hoops & without burning GPU resources on unused pixels.

I've attached a screenshot and a mockup to this post:

* Screenshot "current_wrong_aspect_ratio.png" shows what it looks like when you try to set "Texture Rez" to 1920x1080 for a shader that should show something perfectly round
* Mockup "desired_lock_aspect_ratio.png" shows an idea for this "lock aspect ratio" button, producing the expected 1080p image while retaining the roundness

I think this would be a big win for the folks who have invested time into migrating content to Madmapper's proprietary material format.

There is an interesting use case for this that would immediately simplify my workflow: using texture-render materials as texture inputs to *other shaders*. Let me walk through an example:

Let's say you have a 1080p video playing on a 16:9 quad, and you want to apply a surface FX that takes a separate texture input, like the "Texture Distort" or "Refractor" from the public FX library. At the moment, there just isn't a clean way to use a textured material (or any material) as that texture input and expect that the aspect ratio will match 1080p -- there is no opportunity to do a proper input mapping here. It's possible to address this by adding an "aspect ratio" control in the FX itself, which I've started doing for the FX I publish, but this just means more effort & other existing FX are not usable as-is.

Thanks for your consideration! I feel like this might be low-hanging fruit that would be very very useful

[franz]

can't you just edit your material and multiply uv.x by 1.77 ? - or whatever ratio you need -

[jasonbeyers]

Yes, definitely possible within the material itself. But that would require creating local copies of any material you download from the public library, and needing to do that all over again if the publisher releases a new version & you want to grab the improvements.

This would just be a "quality of life" improvement for a common workflow: download a material from the public library or load any you already have, and change XY resolution (X independent of Y) while retaining the intended aspect ratio, by manipulating the UV coordinates before the material sees them.

[jasonbeyers]

Perhaps the right way to do this -- if there will be no app level button for this -- would be to multiply the centered UV coord by (RENDERSIZE.x / RENDERSIZE.y), so that a material automatically adjusts its aspect ratio when a non-square resolution is specified. This seems to be working fine! However, this only seems valid when the material is in fact textured.

Is there a way that a material can know if it is currently being used in textured mode? If so, is it safe for me to add this to every material of mine, *and* republish the 100+ materials I have in the public library with it?

uv = texcoord - vec2(0.5);
if (is_textured()) {
uv.x *= RENDERSIZE.x / RENDERSIZE.y;
}

The question is: what is the variable or function that would tell me if texture mode is active? I vaguely recall seeing it in some other material, but I haven't been able to track it down, and I don't see it mentioned in the materials docs.

I keep the public library current with whatever version of a material I'm currently using, since I frequently add features to them (while maintaining backward compatibility in case users install new versions in existing projects). So making these changes only in my local copies will prove to be quite the headache for me down the road, as I intend to have this auto-aspect feature in every material of mine moving forward (again, if there will be no app level button for this).

Thank you!!

[jasonbeyers]

Or, is it okay if I use RENDERSIZE by default (and thus, have no need for a check if the material is in texture mode)?

Just wondering if there could be any negative consequences of using RENDERSIZE to adjust aspect ratios when a material is being direct-rendered, like this:

uv.x *= RENDERSIZE.x / RENDERSIZE.y;

I can't tell exactly what RENDERSIZE.xy contains when the mat is being rendered directly, but my guess is that it is vec2(1024). If RENDERSIZE is *always* vec2(1024) when not in texture mode, perhaps it is safe for me to add that single line, to every material? (since in direct mode, the aspect ratio wouldn't actually be changed).

[jasonbeyers]

Update: I’ve solved this on the material side. If you take a look at the 15 most recent materials I’ve published in the library, you’ll see a “lock texture aspect ratio” button at the bottom of the shader controls for each. Seems to work well

[franz]

just multiply by RENDERSIZE.x/RENDERSIZE.y in your material

[zaicik]

Well, I actually got quite the... opposite issue :

I did add aspect ratio correction to my code, but it gives me a wrong result when I'm not rendering as a texture...

Here, Madmapper (5.5.6-demo on MacOs Sonoma 14.6.1) seems to be passing a non-square RENDERSIZE. (I initially though it was passing my actual screen size, but then realized that just resizing the viewport changes RENDERSIZE in the app)

Which if I understand materials correctly... it shouldn't do (though I'm just starting with projection and shading so if I got this wrong, kindly explain pls. This might be a bug, but I might also very much be a noob)


To illustrate, here's a sample code with a pretty circles:
(there's also a quick fix in the form of a "Fix ratio 1:1" checkbox)
Procedure: render normally (not as a surface), don't check my magic box, and your circles will probably look elliptical. Then resize the madmapper window to very flat or to very tall and thin for a more dramatic effect.

Here's also a screen capture: MadMApCapture on Canva



Sample Code:

Code: Select all

/*{ "DESCRIPTION": "Creates a linear gradient from one color to another", "CREDIT": "by VIDVOX", "ISFVSN": "2.0", "CATEGORIES": [ "Examples" ], "INPUTS": [ { "NAME": "Freq", "TYPE": "float", "DEFAULT": 10.0, "MIN": 0.0, "MAX": 30.0 }, { "NAME": "Thickness", "TYPE": "float", "DEFAULT": 0.5, "MIN": 0.0, "MAX": 1.0 }, { "NAME": "lock_asp_ratio", "TYPE": "bool", "LABEL": "Fix ratio 1:1", "DEFAULT": 0 } ] }*/ vec3 palette( float t) { vec3 a = vec3(0.50, 0.60, 0.60); vec3 b = vec3(0.60, 0.50, 0.50); vec3 c = vec3(1.00, 1.00, 1.00); vec3 d = vec3(0.45, 0.47, 0.51); return a + b*cos(6.28319*(c*t+d)); } vec4 materialColorForPixel(vec2 texCoord) { vec2 uv = texCoord - 0.5; uv.x = uv.x*(lock_asp_ratio?1:RENDERSIZE.x / RENDERSIZE.y); float d = length(uv); vec3 color = palette(d + Thickness); d = sin(d*Freq); d = abs(d); d = Thickness / d; color *= d; return vec4(color,1.0); }

My feeling is: although the documentation clearly states then RENDERSIZE is only valid when rendering textures, it could be a good idea to pass a standard 1:1 value for it when used as a material, to make scripts more portable and ubiquitous.


Cheers!