Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Esger van der Post

Pages: [1]
Im currently working on a filter which uses a number of iterations. More iterations increases rendering time as you would expect. So I have a switch set up to select a number of iterations. However, the selection is calculated by a value processor which sets the selection of a multi-switch.

I noticed that performance is always worst-case, as if all iterations are rendered no matter what selection is set by the input value.

I set up a simplified example to demonstrate the issue.

(direct gif link, in case it wont load

As you can see, I have the exact same graph except the multi-switch is exposed through a value input on the 'bad' version, and gives always worst-case performance.

I attached the example graphs below.

I regularly work on filters that take a large number of samples or iterations and it can be a real headache when you expose a new variable for one of your iterations and to connect it in your main graph to, say, 64 iterations of that subgraph.

I just added a new input to this function

And now I have to reconnect it, indeed, 64 times.

For me, this situation comes up on the regular.

Functionality wise, I imagine something like this:
First you select the node with the output you want to connect. Through a button load this selection as "source node". Then either by output number or by identifier select which output will be connected to the group of receiving nodes.

Now select the group of nodes that will receive the new input. Press a button to load in this selection as "receiving nodes". Then select which input all of these nodes will connect, by number or identifier.

Finally press a button to connect the selected output to all of the selected inputs.

I imagine this might be possible through Python, but I personally have little programming experience, so don't really know where to even start.

I regularly use the delta sliders to change the brightness of multiple gradient map inputs, but this has a chance to move values out of range.

You won't notice this until you input a grayscale image that has potential out-of range values, because on the widget it isn't visible that colors are out of range.

I noticed there is a clamp button that addresses this. Could this be enabled by default? I don't think the average user would know to press this. (took me long enough at least)

When changing the 'tiling' parameter in opengl, height scale is automatically updated internally.
But in Iray this does not happen and you have to change it manually.

I'm honestly unsure which behavior I prefer. The automatic updating is convenient, but makes it less intuitive when matching height scale of your scene with the height scale of your normal and ao map.

When using a sharp light as part of the environment map, I noticed Fresnel looks very asymmetrical when the light is placed at certain angles.

Also, the diffuse component has a large brighter spot in the back.

The environment is just a flat ground color and sky color with a bright disk as light source. (I attached the graph for it)

Some of the new panorama nodes have a shape input,

but there is no option to actually use this input.

Using a pixel processor for some contrast adjustments, pow turns black parts of the image white sometimes when switching to the CPU engine.

The levels node doesn't seem to have this issue on the gamma slider, but I'm using many other adjustments on filters that suffer from this issue, so using a levels just for the pow would be problematic.

The odd thing is, this issue does not occur when using a value of 0 inside the node itself.
But when the value is sampled from outside, whether it is a pixel or a input value, results are wrong.

It seems like the hue value on the tile nodes doesn't wrap around properly.
So, starting with pure red only randomizes half the tiles in a range between cyan and red. Hue[0.5, 1]

You can still get the full range by setting the base color as cyan, but a partial range near red is now impossible.

Substance DesignerSubstance Designer - Technical Support - Resolution bug
 on: September 05, 2019, 02:00:17 pm 
I posted about this issue a little while ago. (,29376.msg113801.html#msg113801)
And it seems to be partially fixed, but I'm still having issues in some cases.
I attached an .sbs that I can't currently get to behave correctly when placed as subgraph (As visible in the 'test' graph)
You can see the node just displays a solid color instead of the noise from the graph.


An interesting new prospect of the value processors is that we can now combine relative to parent values with absolute values. I've been trying to use this to adjust nodes' absolute resolution that is capped by the graph resolution.

This works like a charm, until I use the graph as a child. In some cases it works for a moment but after a while the child node suddenly outputs an image that appears downsized.

In the example in this gif(, I can only get a completetly downscaled result, but like I said, in a previous attempt it would work temporarily so it's a bit inconsistent.

When using the widget, values seem to snap to the closest 0.01 value, but this seems to only affect the visual number, not the value that is used internally.
Only when first changing to a different value, and then typing in the correct value, do you get the desired exact value.

I used the safe transform to show the issue, but any parameter that uses the widget seems to have the same inaccuracy.

I also noticed that any manually typed in number gets rounded off to the closest 0.01 value. Again, only visually, not internally.

So, ideally:
- the widget snaps to either the closest 0.01 or to the closest degree, but is also snapped internally.
- The widget displays more decimals, in case you type in a specific multi-decimal value.

Hi, I just noticed my chosen labels for bool buttons aren't appearing in sbsar's. In designer they just appear as true and false, and in player as on and off for some reason (Check images here Am I doing something wrong here, or is this a known issue?


This has been happening for a few days now. since a few days before SD updated to 2017.2.3 on steam, oddly.

I have been messing around with a few materials pretty much since the contest started but finally decided on which one I'll go for.

This is the reference I'm using
I don't intend on sticking to close to it.

For now I've mostly just been focusing on making my own cell generator so I can make some different patterns, and figuring out how to make rounded bevels that work for different shapes of different sizes. So no gold yet.

When a transform is at a different resolution as it's input and has some offset, it becomes kind of pixelated.

Normal, expected result:
With offset:

Replace the transform with a warp, and you will see the same result in the warped areas. (While directional warp does not have this issue)

An even weirder one:
No offset used, and the transform outputs a nice smooth image, yet somehow the following warp is pixelated.

I'm using bilinear filtering and automatic mipmaps on all transforms here.

Pages: [1]