Xhip Effects - Skinning

[Teksonik]

I believe hue, lightness/intensity and saturation are far more natural or "human" ways to look at color represented by scalar (ordinary every-day) numbers. The ways we've grown used to with computers are actually "machine" ways to represent colors using bytes or hexadecimal rules based upon specific computer formats.

The point is we are used to it....RGB or Hex colors. This just seem like complication for the sake of it....

I'm a fan of simple colors. Just give me RGB 120,120,124 or Hex #78787c for a background.

[bwwd]

I dont see any config adb file to download or any readme how to name it so its modifying specific plugin, thre are no tutorials for this at all, this is really discouraging no matter whats the excuse for ommiting tutorial/example but maybe you dont want people to actually try it.Spent 20 minutes figuring it out, made my txt file, but i have no clue what plugin was changed.I know its harsh but thats how it looks like when i try.It should be provided on the table if you want people to tinker with it.We have just bits and pieces.
Whats the actual step by step to change one simple thing in lets say reverb plugin ? Change texture of the background and ideally graphics of the knobs.
Explan please like im 5 years old.

[aciddose]

Whats the actual step by step to change one simple thing in lets say reverb plugin ? Change texture of the background and ideally graphics of the knobs.
Explan please like im 5 years old.

This system is still under development and so things can change or improve.

Where depends on your platform (windows or linux), but on windows you'll find it in your home directory under a hidden folder called "appdata/roaming/xhip/effects". If you have Windows 10 you can open the file browser window or a text editor and type "~/appdata/roaming/xhip/effects/config.addb.txt" to load the file.

(Documentation needs to be improved.)

The file config.addb.txt is a simple database file format. If you'd like to change the knob to use a knobstrip bitmap (like you can generate with knobman or many other tools), first you need the bitmap.

The simple way to test it is to download an existing "skin resource" installer such as: (edit: 7z!)
XFX skinres installer: knobs, 7spline_b 33px + 66px

Once you have the skinres knob strip bitmaps installed, edit config.addb.txt like so:

Code: Select all

knob {
	type = strip;
	color = named(black);
	name = 7spline_b;
}

If you use a non-standard guiscale (not == 2) you'll need different resolution bitmaps rather than the 33px and 66px ones in the skinres package. With the default settings, I get this (this is the alpha version!):


v6.7 will be slightly different since the follower effect doesn't have the extra parameters and modifications:

Code: Select all

How to generate such a bitmap and get it to work (complicated):
I recommend adjusting the file to have a full 360 degrees rendered. You should provide one frame for every nth degree rotation proportionate to the size. This works out to something like (size * 3.141).

So say you have a 49 pixel wide knob (only count the actual knob, not shadows/borders/background) in a 66 pixel frame. That's 49 * pi = ~154 frames will provide sub-pixel rotation and you shouldn't be able to see the stepping of the knob. Often it's possible to use less frames as the GUI framework interpolates between them.

Here's a 3d rendered knob at 66x66 (49x) with a shadow:
https://i.imgur.com/5N3MKzl.png

Xhip uses 32-bit TGA-RLE files. With 7zip compression they're much smaller than other formats. So you'll need to convert your file to TGA 32-bit format using conversion software, if your renderer doesn't already support it. That'll then need to be copied into the resources folder someplace like "/ProgramData/xhip/effects/resources/knob_strip/".

[aciddose]

For the background it seems the alpha version has some kind of blending bug which I'll need to fix. v6.7 though works fine:


Here's the texture:


You'll need to save that someplace like: "/ProgramData/xhip/effects/resources/image/texture/micro_a.jpg".

In your config.addb.txt file add the following:

Code: Select all

background
{
	image = "texture/micro_a" {
		blend = transparent(0x40), xor, delta(0x20202020), scale(0xC0);
		tile = on;
	}
}

It's (should be) possible to disable/hide the logo, all text labels and borders/backgrounds. So that allows you to replace the generated background with a bitmap you've created yourself.

You can include the size in the filename if you like and the GUI framework can select various resolution backgrounds depending on what's needed for the guiscale factor and other properties. For example you could name the file: "micro_a,1170x550.jpg".

Here it is with:

Code: Select all

blend = transparent(0x40);

https://soundcloud.com/xhip/5tuna

[hivkorn]

are you working on gui for OSX version ?!!

[aciddose]

are you working on ... ?!!

See the todo list and the known issues list.

[aciddose]

I've added some basic error reporting functionality. Just using messageboxes for now because it's cheap and easy. Reporting the exact filename/line where the error occurred is a bit tricky but until skins get super complicated it should be easy to figure out where a mistake is.

[aciddose]

I'd tested out full replacement of the backgrounds + all bitmaps and fonts at some point before the v6.7 release, but I've yet to go back and double check that all that still works in v6.7 (I assume it likely does not.)

So here it is in the alpha version with a few additions:


And some knob colors assigned:


I was tempted to open Blender and render the 3d knob strips in some colored glass or something, but since my .blend files don't render right it'll take me a lot of work to re-learn how to set up shaders and the compositor to create soft shadows again.

[aciddose]

(note: I'm dividing what was part of one mega-post into several shorter posts.)



Not quite there... but to get the soft overlapping shadows you'd need to set up a compositor configuration where you render both the normal knob object + shadow plane as usual, but only for sharp shadows that don't overlap outside the ordinary bounds of the frame.

For the softer overlapping shadows you'd then render an additional "virtual" panel as part of the background rendering process. This would use the knob models arranged as expected on the panel in the scene, but they'd be marked as "indirect only" such that they only cast shadows. In addition, the way shadows are handled would be set up with the main lamps set not to cast shadows. Instead, a large "ambient" lamp or set of lamps would be created set to a high distance and size to generate the smooth overlapping shadows pointing in multiple directions across the whole panel. This is where the real headache of such a task comes in as rendering some knob strips is all well and good, but producing a great looking panel with several of the knobs, switches and other objects arranged correctly takes a lot of effort!

The soft shadows would then be "baked in" "composited" to the background and wouldn't change as you turn the knobs. The sharper shadows which let you see the rotation would then be part of the knobstrip.

Rendering overlaps is expensive. So the knobstrip shadows must be ensured not to overlap neighboring knobs. That is quite difficult and is the reason generally very steep angles are used for the shadows even when multiple low-angle lights generate the specular and diffuse lighting for the body of the objects. It's a way to create optimal fake shadows that looks interesting even if it's totally unrealistic in a normal physical situation.

http://xhip.net/temp/blender/7splineb_blender_2.82a.7z

Panning and cropping the rendered region would optimize things as the shadow sticks out on one side, but there is no need to waste time rendering a bunch of additional alpha=0 pixels.

We want the camera angle to be "realistic" as set, but the rendered output window (and therefore rendered pixels) can be cropped and shifted. Panning the camera changes the rendered perspective... obviously orthographic projection is possible but doesn't produce photorealistic results.

Blender achieves this with a render region selected as a rectangular portion of the camera view rectangle. After that's selected "render region" and "crop to" options are enabled in the output->dimensions configuration.

So now it's a matter of "nudging" the knob graphics into the full size widget region. It turns out Xhip Synthesizer implements this, but it doesn't work in Xhip Effects yet. So that's what I'm working on currently.
[/quote]

A lot of semi-unrelated 3d rendering stuff in here, but I hope it'll be useful to demonstrate what's actually required to do what people have suggested. It is possible, it simply requires the investment of effort by an artist who is willing to follow through.

[aciddose]

(note: I'm dividing what was part of one mega-post into several shorter posts.)



The cropping function seems to work. It would also be cool to have larger knobs, although these match the switches and I'll keep them that way for the time being. With frame cropping enabled, each knob frame renders in 1.5s on my system for a 36x size knob body which means ~5 minutes to render the knob strip at that resolution/scale. A modern GPU would really help since I don't have a the ability to run Cycles in accelerated mode.

The cropping function allows for the knobstrips to be smaller size in memory and on disk (bonus for distribution) and speeds up rendering a bit. This knobstrip has more frames than needed (192 vs. ~131) and lands at 422k compressed with default 7zip lzma settings.

Adjusting the lens and cropping a bit differently to get a larger image, I get 2 seconds per frame with a target of 131 = 4.36 minutes. This yields a 7z size of 393k. After I do a bit more work and ensure everything functions correctly (+backward compatibility) I'll post the new .blend file and hopefully a new alpha version.

[aciddose]

I've updated the blender source file:
7spline b r2 . blend (requires >v2.82a)
(These files are © 2020 aciddose made available under CC BY-NC-SA. For other licensing, contact me.)

In addition to rendering the output frames you'll need to assemble them into a knobstrip. This type of thing is trivial and I've written my own tool for it, but it isn't really "ready for release to the wild." After I add some error handling/reporting and information printouts I'll upload it to go along with a tutorial on widgetstrip rendering and my other models (switches, logos, ...) Of course I've meant to do this for the past ten years ... just not much motivation when nobody seems interested.

And now with the cropping adjustments working fully;

Borders enabled to show sizing/spacing/padding/margins (can do solid fills, colors, ...):


Result:


Configuration settings:

Code: Select all

version = 6.6;
guiscale = 1.5;

background = off {
	image = "bg/follower_rasta1";
}

header = on {
	height = 33;
	border = off;
	title = off;
}

group {
	margin = (12, 0);
	padding = (12, 0, 12, 12);
	background = off {
		color = gray(1/4, 1/2);
		shape = rounded;
	}
	border = off;
	label = off {
		height = 40;
	}
	display = off;
}

widget {
	size = (40, 36);
	spacing = (12, 0);
	background = off {
		color = gray(1/2, 0);
		shape = rounded;
	}
	border = off;
	label = off;
	display = on {
		color = named(black);
		background = on {
			color = named(gray);
		}
	}
}

knob {
	size = (44, 44);
	type = strip;
	name = 7spline_b;
	color = named(red);
}

switch {
	type = strip;
	name = slide_switch;
	color = named(green);
	label = off;
}

(I should've used "Truut" for Abs instead of "Jah" )

[aciddose]

Progress on this stuff continues with full implementation for text + background properties. Some color blending functionality is supported allowing mixing/modifying colors using intuitive add/sub/mul/div/hsl.

Code: Select all

// @ = hsl shift, result = hsl(x.h + y.h, x.s * y.s, x.l * y.l)
// result = effect.color hue shifted +1/3 at half saturation with alpha 7/8
color = var(effect.color) @ hsl(1/3, 1/2, 1) * gray(7/8, 1);

Here it is with all text colors set to black:


The database now supports specifying sub-members via point notation like so:

Code: Select all

text.default.size = 12;
text.default.border = on;
text.default.border.color = gray(1, 1) - var(effect.color);
text.default.text.color = named(black);
//text attributes inherited from default =;
//text.title.text.color = named(black);
//text.group.text.color = named(black);
//text.label.text.color = named(black);
text.label.size = 12;

That internally expands to:

Code: Select all

text {
	default {
		size = 12;
		border = on; {
			color = gray(1,1)-var(effect.color);
		}
		text {
			color = named(black);
		}
	}
	label {
		size = 12;
	}
}
//textattributesinheritedfromdefault = ;
//text {
	title {
		text {
			color = named(black);
		}
	}
	group {
		text {
			color = named(black);
		}
	}
	label {
		text {
			color = named(black);
		}
	}
	switch_label {
		text {
			color = named(black);
		}
	}
	display {
		text {
			color = named(black);
		}
	}
}

It may be nice to figure out a way to optimize the output format to utilize this point notation feature where a tree in the hierarchy leads to a single or few leaf node(s), but that's not something I expect will be used to export the database in Xfx anyway.

I see a bug

Code: Select all

border = on; {

Looks like it prints the semi-colon regardless of whether child nodes are going to be printed, but again this is purely a debugging/internal feature so just a novelty.

Also added a color interpreter:

Code: Select all

color = hex(#ff00ff);

Additional prefix symbols such as the leading 0x or $ or # are completely ignored (since a leading zero is meaningless) except in the case of unspecified alpha, where the leading zero would produce 0ff00ff and be interpreted as 00ff00ff rather than ffff00ff with alpha automatically filled in. So a redundant meaningless prefix or symbol is best avoided entirely: hex(ff00ff) will always == ffff00ff. This complication is solved in the stdc library functions by always dropping any leading zero during atoi() in printf and such. That way 0x = hex and 0 = octal with only a few extra bytes of code to drop the leading zero. So if need be I could always add that sort of workaround to my implementation, too. (I won't; I prefer the explicit method "do exactly as I tell you" vs. "whatever you think I told you".)

[Kott]

Hi,
looks like your site is down

[aciddose]

That'll happen now and then. Since the release versions have their pages here on KVR, for the most part the site is only important for current alpha versions and such. It's back up now if you were aiming to grab the latest alpha(s).

[Kott]

I see