SynaGl0w's Sketchbook

Update:


Maliwan Wallpapers.
These are also posted on steam: http://steamcommunity.com/sharedfiles/filedetails/?id=235212739

Burn:


Electrocute:


Corrode:


Slag:


Plain:


Here is a couple of RC wrench wallpapers themed with Tamiya colors:



First one I did quite a while ago while the second was a recent render.

Love your ideas!

Random cap which is a prop from a much larger scene:


Some of the masks are not perfect, but it’s not actually meant to be seen this close.

The bottom RC wrench render looks awesome. It seems like people overuse DoF but this is an exception.

It’s a matter of scale. With a object as tiny as that the DoF is expected to be that shallow.

@SynaGl0w: Great work with those textures… looking extremely good!

I should probably not be ignoring my sketchbook…

So while working on some procedurals I got one that looked kinda terrain’y, so I thought I would give it a whirl.

This test was with true displacement enabled and rendered at 8192 pixels wide. Cycles used ~16 GB of ram during render and the prebuild phase hit 43 GBs of ram:


Here is a zoomed in render:


After some very messy subdivide and un-subdivide action, I rendered this out:


Clouds and foreground detail done in PS. Prebuild phase for that one only hit 20 GB. Rendered at 4k. Other than simple color gradient there are no other textures in the scene. There are some sharp bits of triangles and a number of other problems, but for a fast diversion from what I was doing, it turned out pretty well.

Very cool!

Well I hit yet another brick wall… or in this case a stone path. I thought it might be neat to see some displacement on something else. Unfortunately in this case I cannot have the diffuse stone color plugged in at the same time as the displacement is plugged in.

Got the dreaded non-instant “Updating Shaders” message. Usually this completes after a few minutes.

I tried leaving the machine for 2 hours… came back and guess what: Updating Shaders! :mad: No error messages at all, of course. When this happens only a single thread worth is active (8% of CPU).

If this happens, I can usually get around it by plugging the height into a bump node instead of displacement output to get similar results which makes the “Updating Shaders” instant again. Problem here is I wanted to have true displacement.

Oh well… on to the tests!

Bump Node:


True Displacement:


Lots and lots of triangles:


The problem I know is with my “Rings” procedural, as it already has certain inputs that cannot be plugged into Surface and Displacement at the same time without causing a delay, but I guess adding in some of the stone stuff increased the “Updating Shaders” time from a few minutes to obviously more than 2 hours. Who knows how long it would have required.

Changed vector noise fac from 0.1 to 0.2:


Random wallpaper:


IReally love that landscape with procedurals! Did you do the stone rings with procedural too? I having really worked with procedural textures much.

Yep, the stone rings are 100% procedural. Here is what the basic rings group looks like:


Inputs define sections per ring starting in the middle and increasing by that amount for each ring from the center, unless “Use Fixed Sections” is true, in which case every ring has the same number of sections. Can specify the rotation amount of each ring going away from the center as well as random rotation and scale. Right now the ring rotation is just 0.0 to 1.0 for a complete rotation, but I might change it back to radians.

Outputs include various gradients, random colors per section or ring, various texture spaces per section or ring, and of course a ring number which is good for masking out rings/ranges.

100% procedural:


Needed the displays to change on rotation so transformed face normals are used to generate values.
http://i.imgur.com/gGn3wU1.gif

The value to texture space node system for the digits I have right now is too much hax. I need to rebuild it for better control and efficiency. Curiously, I had some more “Updating Shaders” delays that were pretty long, but when I made the ball shader even more complex, the “Updating Shaders” delay became almost nothing. Less than 2 seconds now.

Fun stuff:

Only got that message with displace output.

I’m really amazed at how those have turned out! That triangular sphere with numbers is crazy. What is causing the slowdown, and all that ram being used? Is your mesh VERY VERY dense?

The sphere is only 3120 triangles. Cycles uses only 18.35 MB when rendering it. The slowdown I am referring to is cycles updating shaders phase when you change something in the shader and have the preview active, or on render.

I can give you credit on one thing, you’re the only known person on this forum who has managed to break the current SVM stack size limit in Cycles (which has already been raised once or twice and is now at 256 nodes). How is it possible that a shader for scratches could get that big?

It could also highlight a need for more node texture types or options for existing nodes, I’m aware of DingTo’s concern on putting pressure on the kernel, which is why there would be a need to show that it would be useful for a large array of common cases.

One of the best examples of your (shader) work here is the radial tile one, especially when you consider that all of the radial lines going out remain at an even width.

Well I remember reading somewhere the small stack limit was a restriction mainly for the GPU… If that is the case, the stack limit really should not be hard limited, at least for CPU. Allow the user to set it for CPU. Got 64 GB of RAM, would like to use for things other than subdivision. Some procedurals can get so complex that using them in a scene at render time is not a good idea, but now that we have baking, the usefulness of these complex procedurals is massively increased.

Never exceeded any stack limit on anything else. Way back when the stack was 64, I hit it almost immediately. Again my main issue is the “Updating Shaders” delay problem which I figured would go up with complexity, but sometimes goes away when the material gets more complex. I don’t have the time right now, but I’ll have to sit down and create some good demo cases and submit a bug report.

Actually I think the worst thing I have done so far was that digital display since it’s all procedural. That has some hellish node groups. The rings group internally has 2 n-gon groups, 2 rotator groups, 2 noise textures, 1 gradient texture, and a few other things. It’s also still a mess inside. :confused: