a shader each day

[cellchuk]

Oh! You are right - it's CMYK - but forward ever backward never.

Day 3: A Silkscreen Shader

This Shader simulates a silkscreen printed piece.

You feed it an image and it generates the colour seperation.

This interesting part was the RGB -> CMYK seperation.

It is a two step process: RGB -> CMY -> CMYK [1]

Again these process doesn't take any ICC or other profiles into account but does a good job for my purpose.

I used the inlineVOP as building a network for this function turned out to be too tedious.

Some matrix fun to rotate the four layers. Well, not that funny if you live in the matrix.

I guess this shader is going to play a major role in my new music video.

20080424_rdg_silkscreen.hip

[1] http://easyrgb.com/math.php?MATH=M13#text13

great shader man.

[Andz]

Really nice work rdg!

Reminds me a lot THIS texture for max.

[Matt_K]

Nice stuff!

Thanks for the effort!

Matt.

[rdg]

Day 6: Rotated Letters

Today I implemented the random rotation for cells.

Instead of using a matrix/rotateVOP I wanted to convert the rotate2D function from the vexnotes.h [1]

The Vop network for this rather "simple" function was very unclear and - guess what - didn't work.

After entangling myself I switched to inlineVOP again. Took some time though due to wrongly named variables.

I am sorry for the rather sluggish network ... it's getting messier every day.

But I need to do some other stuff, too - happens seldom enough.

20080429_rotated_letters.hip

(requires letters.rat from one of the previous posts)

Tomorrow's shader might include the scaling part of texture bombing.

I try to combine all those techniques into a silkscreen shader that uses letters/symbols instead of dots.

[1] http://odforce.net/happy_rendering_with_ve.../vexnotes.h.htm

[rdg]

Day 7: Letter Clusters

I implemented the next step for texture bombing:

Layering different layers of random textures.

I must admit I didn't quite get the forLoopVOP at first glance.

Still there are some unresolved issues as the system outputs nice images, but not the one I would expect.

20080429_today.hip

today's hip file is just for archiving.

I will rework this texture bombing lecture from the ground up now that I think I got it.

There won't be any updates for some time as I'll be on holidays and visit FMX next week.

Cheers,

Georg

[sanostol]

have fun at the fmx

You are doing great stuff here!

martin

Day 7: Letter Clusters

I implemented the next step for texture bombing:

Layering different layers of random textures.

I must admit I didn't quite get the forLoopVOP at first glance.

Still there are some unresolved issues as the system outputs nice images, but not the one I would expect.

20080429_today.hip

today's hip file is just for archiving.

I will rework this texture bombing lecture from the ground up now that I think I got it.

There won't be any updates for some time as I'll be on holidays and visit FMX next week.

Cheers,

Georg

[crunch]

Day 5:

Tried to solve the dirt issue in my tiled shader.

I tried to blame rounding and/or float vs int but it didn't help.

Reducing the filter width in my textureVOP to zero removes the dirt.

I don't think it's good to jump over this issue as it will surely crush me from behind in the next days.

The texture() function uses the surface derivatives to sample an area of the texture map.

My guess is that what you're experiencing is most likely due to the fact that you're using a modulo function, or some other function which has discontinuities.

What you might try doing is using passing the derivative information manually to the texture function(with the appropriate wrap mode of course).

The key explanation is in that ASCII art

	float	ss, tt;	// Texture coordinates
	float	dsdu, dsdv;
	float	dtdu, dtdv;

	// Approximate rectangle of coordinates *before* modulo operation
	dsdu = .5*Du(ss);
	dsdv = .5*Dv(ss);
	dtdu = .5*Du(tt);
	dtdv = .5*Dv(tt);

	// Now perform modulo
	ss = ss % 1;
	tt = tt % 1;

	// Consider the case where we were shading the micropolygon.  The
	// ss coordinates across the micropolygon are something like
	//
	// Before the modulo
	//	 ss=0.99 +---+ ss'=1.01
	//
	// The derivative is (ss' - ss) = 0.02
	//
	// After the modulo
	//	 ss=0.99 +---% ss'=0.01
	//
	// The derivative becomes (ss' - ss) = 0.98
	//
	// So, the default texture function will end up filtering the
	// entire texture into that little seam at the edge of the map.
	//
	// The alternative is to manually specify the area that we want to
	// filter (based on the pre-computed derivatives).

	// Now, manual specify the four corners of the texture area to be
	// filtered, something like...
	Cf = texture( map,  ss-dsdu-dsdv, tt-dtdu-dtdv,
			ss+dsdu-dsdv, tt+dtdu-dtdv,
			ss+dsdu+dsdv, tt+dtdu+dtdv,
			ss-dsdu+dsdv, tt-dtdu+dtdv, ...);

I hope this makes sense.

[rdg]

I hope this makes sense.

It makes sense, I just need to implement it.

I had the luck to be with oldschool at the FMX, where he told me that one usually multiplies the modulo with 0.995.

Which also makes absolutely sense to me, but doesn't change anything ... I guess I misunderstood something.

As FMX also washed me to the Glasgow shores - if it got any - I will need some time to acclimate, before I return to this tai-chi like lessons.

Georg

Edited May 13, 2008 by rdg

[rdg]

Day 8: Chimera

Implementing isn't the right term as I just copied your code.

I am slowly understanding it.

oldschool also thought me that switches are no good.

So I changed them to filtersteps with very small filter width.

The aliasing is coming from the texture itself.

I used a a set of images from the "processing book" by Ben Fry and Casey Reas[1].

So the texture template looks like this:

The bombs get combined from two different slices.

20080517_vexhack.hip

OPcustom_random_tile.zip

items.zip

I try to clean up the code - which is very messy - the next days.

[1] http://www.amazon.com/Processing-Programmi.../dp/0262182629/

[Andz]

Sheepgun, Snailphone and Chickenmug :-)

This is something completely new to me, that I didn't even know it was possible to do with textures.

That processing book looks really tempting, do you like it?

[rdg]

That processing book looks really tempting, do you like it?

It depends.

If you are looking for 3D algorithms: no.

If you have an affinity to reading pages of simple code examples: yes.

If you are teacher or interested in teaching "language like programming environments" - and I definitely would put Houdini here: YES.

There are a lot of good paragraphs about teaching and learning complex systems in it.

[Mario Marengo]

The texture() function uses the surface derivatives to sample an area of the texture map.

My guess is that what you're experiencing is most likely due to the fact that you're using a modulo function, or some other function which has discontinuities.

Hey crunch,

I just read your post, and everything you say makes perfect sense, but I think that what rdg is seeing is a different issue (related perhaps, but different). I made some tests and would love to hear your take on this.

In the "classical" bombing scenario, you set up a virtual grid of cells over the bound texture uv's. Each cell is a 1X1 domain where each bomb is placed. Each bomb's extent is restricted to a maximum size of 1X1 and allowed to be placed at a random location within the cell (which implies the need for a unique ID or random seed for each cell). The shader then loops over a 3X3 cell neighborhood (to allow for overlaps) placing a bomb in each cell. This is different from a pulse train where a modulo would be involved (and be subject to the issues you mentioned).

Here's a simple version of that classical setup:

surface bomb2(

string map = "";

float bfreq_u = 10;

float bfreq_v = 10;

vector uv = 0;

)

{

// incoming uv's

float u=s,v=t;

if(isbound("uv")) { u=uv.x; v=uv.y; }

// underlying bombing uv's

vector buv = set(u*bfreq_u, v*bfreq_v, 0);

// central cell coords in the virtual grid

vector cell = floor(buv);

vector C = 0; // final bomb color

// loop over the 9-cell neighborhood centered at 'cell'

float i,j;

for(i=-1;i<=1;i+=1) {

for(j=-1;j<=1;j+=1) {

// c = the test cell

vector c = cell+set(i,j,0);

// p = the bomb pos within the test cell

vector p = c + random

[rdg]

hm.

I always wondered why my shader doesn't use this 3x3 grid techniques

Might be caused by my reference - the vex bomber in the wiki - which uses layers.

Mario also kindly started to explain and discuss some "point cloud bases decal scattering" techniques.

Which should lead to some results in the near future.

Potential uses for "pcdb - point cloud decal bombing" might be adding details to large textures without the need of high resolution texture maps. Or maybe some radar shader that traces positions/silhouettes of ships/planes onto a radar screen.

Greetings from Glasgow

Georg

[rdg]

Day 9: Constant width sprite outlines [1st try]

Peter Robbins asked me about a shader that renders sprites as if they were selected in the viewport.

I used four filterstep functions to create the outline.

The width is modulated by the spritescale ... in least in theory ... something went wrong and a few of the sprites get thicker outlines.

My good old friend the derivative seems to contribute to this game and adds some variations ...

Anyway ...

I added a VOPSOP template to generate sprite properties without using a popnetwork.

rdg_sprites_selected_odf.hip

Edited July 25, 2008 by rdg

[Andz]

Hey RDG, nice to see this thread up and running again ;-)

Realy nice image you got there, if it wasn't for the depth of field, I'd say that is looks a lot like a vector illustration.

Keep up with your research!

[Jason]

My good old friend the derivative seems to contribute to this game and adds some variations ...

Anyway ...

So do your results get much better (cleaner, more consistent) if you bump your shading quality to 2 or 3 or so?

I've seen shading quality make a huge difference to a lot of those NPR style renders. It's probably worth making a material which always has a boosted Shading Quality by default, I think.

[rdg]

Andz,

Thanks for waiting - I missed me too

I finally found my way to "tchainova" - a tea pub across the street, that offers: "buy some tea - get wifi free".

Day 10: dashed selected sprites

The boxVOP seems to produce far more stable results. I'll try Jasons shading quality tipp next - and rework my "constant width" approach.

Also I need to copy the derrivate snipped to test it with this shader ...

The boxVOP is mixed with a wirepatternVOP to generate the dashes.

...

Yes, upping the shading quality makes a difference ... thanks Jason!

So many parameters, so little time.

Day 11: RDGautomaton - not a shader

This no shader at all. It's a pythonSOP that generates cellular autmatons as descibed in "A new kind of science" [1].

I get the impression that a VOPSOP might be way faster. It's b/w as I didn't understand how to multiply colors in python.

[1] http://www.wolframscience.com/nksonline/toc.html

Edited July 27, 2008 by rdg

[rdg]

Errata Day 9:

After having a second look at my "constant border width":

I completely forgot about Z - and I guess the borders have a constant with - the distance to camera makes them fade.

Therefore my next version should take Z into account.

Day 10 version looks like constant width as the width is just 0.01 s/t and in almost any case will be rendered as just one pixel.

Edited July 29, 2008 by rdg

[ykcosmo]

wow, very cool!!!

[rdg]

Another Day

I had the chance to speak as an opening act for "Oldschool Blog Live!" at Siggraph2008.

The presentation was about cellular automata as an example of Houdini's workflow: creating complex results from rather basic rules.

You can download the presentation, the OTL and a example file from the exchange:

http://www.sidefx.com/index.php?option=com...er&Itemid=8

As a bonus for my loyal odforce readers - here is the annoymentSOP:

annoymentSOP.hip

It utilises the new 9.5 scriptSOP - just dive into the network and press play.

Cheers,

Georg