shader mixer: rotating the pattern from a Wood brick

sriesch

How do I rotate the pattern generated by a Wood brick? I'm not even sure what brick(s) I would use to accomplish this.

Richard Haseltine

Well, the short answer is that you use the bricks option menu to Show Advanced, which gives you an extra Point input that controls the pattern. However, after some fiddling I'm not sure how the values are turned into wood patterns so a considerable amount of experimentation will be required unless someone else happens along to fill in the blanks.

Bejaymac

TBH I'm not sure if this can be rotated, it's 100% procedural which means it completely ignores the UV of the mesh, and it looks like the pattern is set to run along the length of the Z axis based on the mesh origin.

Richard Haseltine

Well, this takes the UVs and does some trigonometry on the U value to get a pair of numbers making a full circle as the value goes from 0 to 1, then feeds those into the x and y values of a point and adds the v to the z value, scales the point up, and feeds it into a wood brick. It might make a basis for experimenting that could then be transferred to a network based on the geometry rather than the UVs of a model.

Richard Haseltine

Ah, I was being dense when I looked at this last night. Take a Variable brick and set it to P, the point being rendered. Them the step I was missing, transform from Current (which is Camera space) to object space. Then use Matrix Transform to rotate, scale or translate that as desired and feed it into the Wood brick. You will need Show Advanced on both the Transform and Wood bricks for this.

mjc1016

Richard Haseltine said:

Well, this takes the UVs and does some trigonometry on the U value to get a pair of numbers making a full circle as the value goes from 0 to 1, then feeds those into the x and y values of a point and adds the v to the z value, scales the point up, and feeds it into a wood brick. It might make a basis for experimenting that could then be transferred to a network based on the geometry rather than the UVs of a model.

That's what I was thinking, too...something like a custom rotation with a lot of math bricks.

Bejaymac

Not sure how to phrase this, but I get the feeling the wood brick projects the effect onto the mesh, normals facing "front & back" that are aligned to the Z axis of the mesh origin get the end grain (growth rings) of the wood effect, while the grain effect is projected onto the normals that face "front & back" along the X & Y axis of the origin, which is why it looks like a plank of wood instead of a bad veneer job.

Richard all I'm getting from your network is a "bad veneer job" (see attached pic), all it's done is "randomized" the direction the grain runs, while at the same breaking the "procedural" effect as it no longer works on a mesh with no UV.

Rofl, ninja'd, I was to busy messing with your first network to notice you had posted a second lol

Richard Haseltine

I was thinking the first would serve as a basis for figuring the brick out, though it would also be useful for applying wood to UVed surfaces on a model that was too complex for the carved-out-of-a-larger-piece procedural effect.

sriesch

Richard, I just tried the second method, and a few quick tests indicate it seems to be working for me, thanks! Plus, the matrix transform brick will let me eliminate 8 other bricks I was using to adjust the scale. However, I would also like to understand why it works. I understand what the matrix transform brick controls do (although I don't understand how the Point type it outputs can contain rotation and scale information if it consists only of X, Y, and Z coordinates). However I don't understand what you mean by (or why you are doing) "transform from Current (which is Camera space) to object space" using the Variable[Fixed] and Transform bricks.

Richard Haseltine

The P variable returns the location of the point on the surface that is being rendered, but it does so using coordinates that are centred on the camera being used to render with the z axis pointing out of camera, the x from its side and the y from its top - so if you feed that to the Wood texture you will always be looking down the length of the virtual piece of wood. Transforming that to the object space changes the coordinates so that the origin is at the object's origin and the axes are aligned with its default orientation, which means that a given point will always have the same values no matter where the object is placed or how it is scaled or rotated. The matrix transform then takes that point and generates a new one, rotated around the objects centre etc., and then feeds that to the Wood brick so you get the result for that point in the imaginary block of wood that spans the universe instead of the result that belongs to the real point on the object.

sriesch

Thanks for the explanation!

sriesch

I just noticed the following warning in my log file. Am I doing something incorrectly, or is it a warning that should be ignored?

Compiled C:/Documents and Settings/Sean Riesch/Application Data/DAZ 3D/Studio4/shaders/brickyard/{64a72e5e-98d4-4013-a940-fd85056a10d0}/shader_Surface.sdl...
stdin: in function shader_Surface stdin:465: WARNING: type mismatch for argument number 2 of 'translate': 'vector' expected instead of 'point' (near 'column 266') stdin:472: WARNING: argument number 3 of 'transform' function should be in '"current"' coordinate system (not in '"object"' coordinate system) (near 'elr_148ef8c8_d369_4731_bc64_028d73a9cb2e_token_48')

Richard Haseltine

I've seen several type mismatch warnings in the last build or so, at first I thought it might be related to the problems with slow-down using LIE. I have reproted it as a bug, but it doesn't seem to be causing any render-time issues.