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.

Messages - CodeRunner

Pages: 1 [2] 3 4 ... 12
Okay, yes, I've noticed this behavior a couple times. Something similar (strange) happens when you change the type of a variable in the sub-graph (such as from float3 to float2) when it doesn't match the default value. Its like the extra component value garbles up the variable value read.

Does it resolve the issue you're referring to by completely deleting the instance of the first graph in the second, then re-adding it? Since it has been so long since I deleted the exposed variable, I would have a hard time remembering anything about it. If not, what about copying & pasting the parent graph? Does the issue get copied with it?

I can, but it has a ton of custom dependencies. It's a graph I've been working on for months, so it has become a bit cumbersome. I'm not sure it would do any good to send it by itself? Let me know if you still want to look at it.

If anyone can just help me understand what that error means (ERROR_UNKNOWN_INSTANCE_PARAMETER_NAME), I can probably figure out the problem. Google didn't turn up much. I wasn't sure if it meant I had an exposed variable with no usage, or a usage with no variable, or something else entirely. The names of these two variables definitely sound familiar, so I'm sure it is something I changed and didn't complete properly.

If I expose the variable of a sub-graph, and then expose/attach that to a parent graph variable, then later delete the sub-graph variable entirely, will this cause any issues for the parent graph? I'm pretty sure I did this a few times. When I went to clean up the parent graph, it appeared to already be correct. But I wondered if it created some type of ghost bug.

I didn't know much about the global random node. Thanks!

As far as not randomizing per pixel - that was the biggest reason I was initializing variables in the output size function. So any randomness would only be processed once per image instead of per pixel. As long as the random node isn't executed inside the pixel processor graph itself, you can still get away with using normal randoms in it. But there appears to be a small bug that prevents the output size function from being called sometimes before the processor is ran. That was the primary reason for my post. I hope this will be corrected some day.

As for using the value processor, I still believe this node needs some type of "inherit random seed" option, but setting each instance of it to use a different local seed along with the relative-to-parent setting seems to work okay. But if you create 2 or more instances of the parent graph (parent->value processor), they would also need to have unique seeds set to ensure all internal value processors generate unique results.

It would make it all so much easier to have a simple "inherit global seed" option, or "inherit top-most seed". Something where all child nodes rely on the same random generation pool. The FX-Map nodes have this for the same reason - to allow each instance of them to spawn different results (without manual per-instance intervention).

Thanks again guys.

Vectors are used for quite a lot of data in some graphs, and Substance Designer lets us give the axis component names (X=Power, Y=Ratio, Z=Falloff, etc), but when we build graphs, it can get very confusing as to which axis represents what. Something that would be a huge benefit would be a small text string on the swizzle axis node components that contains the custom string we assigned to that axis. For example..

Pretty please?

So I just figured out how the bakers work in Designer, and I was wondering if there is any type of automatic association that can be done, similar to how Painter works.

For example, is there any way to create a smart filter that automatically makes use of a curvature map when one is available, without having to manually place the baked curviture onto the graph as a bitmap and plugging it into the filter?

If not, a great feature to have would be some type of "mesh information" connector, either manual or automatic (preferably automatic), that a sub-graph could use to associate any mesh maps with, such as curvature, position, AO, etc.

Designer has a more open (advanced) work-flow than Painter when it comes to features and control, but Painter still wins out because of its automatic association, which allows lazy (productive) features like smart materials.

We need this in Designer!

Geez, I found the "Self Occlusion" option for AO to do exactly this thing, even when the mesh is split up, so my example was a really bad one. However, the option to split or not split, per map, would still be very useful :)

Currently, we have to decide as a single global choice to have the bakers separate objects based on IDs or to deal with them all at once, but there are many situations where it makes sense to do one thing on one map and the opposite on another.

For example, any type of furniture that has multiple elements (metal and wood) attached to each other with nails or such. We definitely want our AO to spread between the elements (so the metal and wood influence each other), but we don't want our normal map to get mixed up and confused where the elements are touching (the reason the explosion options are there to begin with).

Currently, a user must bake multiple times, changing the options in between, which works well enough for now. But it would be really nice to have a checkbox (per map) to make this happen automatically.

I'm getting the following cooker warnings, but I'm not sure how to locate the problem:




My primary graph ("Grime") is a little complex, which is the reason I'm having trouble locating the issue. I've tried using the search bar, but all nodes become faded out with both of these variable identifiers typed into the text box. Do these warnings mean the variables are being requested somewhere, but don't exist? Can anyone help me figure out how to narrow down the locations of these issues, or just to understand what the issues are?

I know they are just warnings, but would still rather clean them up if possible.
Thanks for any help!

Thank you very much for the information. Its a bummer we can't use fractional values to drive random seeds. Perhaps it is something that can be corrected in the future?

I wish Designer had some type of high level warning system for stuff like this. Your users will spend a lot of time creating graphs a certain way, then find out later that something is broken or errant, for no logical reason. Then they have to spend even more time tracking down what they think is their own bug, only to realize that its not a bug at all - just a situation that wasn't handled correctly by the system. I'm stubborn, and I love these programs, so you won't lose me as a customer. But its probably enough frustration to drive some people away.

Ok, but do we know why? If I remove the multiply and add 60.0 instead, it still ends up having the same issue, so I don't think it has anything to do with multiplication..?

Does anyone know the reason this is happening?

Random seed doesn't seem to have any numerical limits in int form, so I don't think it's because the value is reaching a threshold. And any type of math I try works fine using constants, so it appears it might be related to the runtime conversion from float to int?

We really need a way to allow nodes to share the same random seed, similar to how you can inherit a random seed in an FX Map. If there is currently a way to do this, please let me know. This is really important, especially for the new value processors, which must have their own random seed in order to produce different results per instance.

So, for example, if you create a value processor graph that generates a random result, and you have 5 of them in your main graph, you have to give all 5 of these instances a unique random seed to get 5 unique results. And what if you add a 6th one later somewhere else and want a new random number. You may accidentally choose the same random seed as another and create an accidental relationship between two distinct parts of your graph.

If would be great if we could link ALL random seeds in a single graph to a single pool, making them all generate random instances from the same deck. An option to inherit the parent's seed like an FX Quadrant would be perfect for this.


Please check out this situation where I'm trying to expose a random seed as a floating point value. I'm multiplying the floating value by 250, then converting to int for the seed. But for some reason, once the floating point rises above 0.28, all random results are identical. Does anyone know why?

Note that I am using the new value processors to show the problem and display the results, but this has nothing to do with the issue, as this same issue has been causing me distress since before the update. It appears that any random seed over (around) 77 generates identical results. But only when a variable is used to process the math. If I switch the math to rely on constants only, it works fine.

Please let me know if this is a bug or just something I am doing wrong.

Yeah, I'm loving the concepts of the new engine, but I'm not completely in line with the logic (my brain is lagging behind). Would I need to setup 4 separate value processors and plug all 4 into the pixel processor for something like this..

On another version of the same processor type, I'm setting 12 values. Would I need 12 logic processors and 12 inputs? Or is there a way to stream multiple data connections?

Another concern is randomness. If I make 4 logic processors that do the same random thing, will they all come out identically unless I manually set their random seed? Would there be any way to force each execution to be different (like force it to use the external/parent random seed)?

Is this new stuff in a manual somewhere?

Thanks for the advice!

Substance DesignerSubstance Designer - Feature Requests - Link Tool Tips
 on: May 09, 2019, 03:46:51 pm 
A simple but useful feature to add would be link tool-tips. When the user hovers a node link, a tool-tip can appear that shows the name and connector of its connected nodes. Something like..

Output: Uniform Color: Output
Input: Vector Warp: Vector Map


Parent: Base Material (Roughness)
Child: Warp (Gradient Input)


Base Material (Roughness) <-> Warp (Gradient Input)
(where the <-> is a little icon or symbol)

When developing large graphs (where certain nodes are grouped together into a frame that links to other framed clusters of nodes), I find myself constantly needing to scroll around to figure out (or verify) which node is at the other end of what I'm working with. Something like this would be very convenient. It should also not interfere with anything, and be pretty simple to include.


Okay, that's what I figured. Thanks!

Pages: 1 [2] 3 4 ... 12