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 ... 12
1
I've been using them since you posted them and haven't noticed anything at all. My guess is they are solid. Thanks!

2
For all of the perfectionists out there, please add an option that forces nodes to always land on grid cells :)

So with the option on, it would be impossible to place a node in between grid cells (the top and left edge will always align with the grid).

Thank you!

3
When a bitmap resource is missing, and the user uses the "relocate" feature to select a new location, the "!" symbol does not get resolved or removed, even if the graph is closed and reloaded. This doesn't seem to be the case with other resource types such as meshes.

The bitmap is showing up in the graph and being deployed correctly, but the graph still shows the "!" on the graph name, the resources folder, and all of the bitmaps in question.


4
Thanks, that's a very intelligent way to handle it. Does all of this get inlined by the optimizer? I have a few somewhat ridiculous situations where I swizzle many nodes into instances of the same graph, such as to generate random numbers. I made something similar to this swizzle, but then ended up making direct versions out of fear that it wouldn't be optimized.

Thanks again, very useful!

5
Unfortunately, that's not the case. I've had that option disabled since I installed.

Whatever it is sending seems to be rather large. It outweighs everything else I have running, including playing Street Fighter online. Here is a snap of a few seconds of logging. This is with the privacy option disabled, and Designer in the background.


6
Why does Designer constantly transfer data over the internet? This seems really strange for an image editing software.

If it is some type of anti-piracy measure, then does it really need to send it constantly? At the very least, it should only do it while the app is in focus. Wouldn't such people would block it from accessing the network anyway?

I love this software, and will continue to use it, despite problems like this. But I really wish the top level guys would stop suffering the people who pay to fight the people who don't.

7
Something that would really help your users is an automatic file copy of the most recent autosave after a crash. When Substance Designer opens after a crash, it should compare the most recent autosave time stamps to the primary related files of everything that was open during the crash. Then a second dialog can appear, asking the user if they want to replace those files with the more recent one. If the user chooses yes, Designer can move the primary files to the recycling bin (or copy them to an autosave instance file), then copy the more recent autosave versions into their place.

Some users probably don't even realize they can regain lost progress by restoring these files after a crash. Others may not be computer proficient enough to compare the time stamp to see which is more recent (their file or the autosave). And then there are those who know how, but still find it a chore. Especially right after losing progress to a crash (or power failure). This feature would help everyone.

8
Awesome, thanks! I made my own for now, but some type of built in system would definitely be an improvement.

9
For future searcher record, the value processor concept seems to work pretty well. I created a graph that generates 4 random values (vector 4) using a value processor, then had to create a graph to swizzle the components apart for each instance of the sub graph (tool graph). This allows the sub graphs to all rely on the same random generation pool, which means they are all independently random. They all rely on and use the same random seed.

Having multiple graphs rely on the same random pool is extremely important and needs to be a feature! It would also be so very easy to add this feature. It may even already be possible through some hack I haven't considered (apart from value processors). But it should definitely be added to the UI as a simple option. Just an extra option in the random seed type drop down. "inherit from parent graph"

10
There seems to be no way to output individual components from the vector-output of a value processor. It is often necessary to generate multiple floats inside of a value processor and output them as a vector (because only one output is supported). But then there is no way to split up those values to send them to separate nodes.

We either need a swizzle node, or the ability to output more than one value from the value processor.

It is possible to create our own swizzle graphs, but we would need one for every axis of every type of vector. Something like 9 graphs, I think?

11
I could get behind that, but I'm still not able to have 4 instances of the same (tool) graph randomly offset by different amounts. Regardless of what random seed I choose in the parent graphs, all 4 instances offset in sync with each other.

Since we're not supposed to use multiplication to generate random seeds, it means all 4 of them are the same value plus some arbitrary hard-coded value. Which means they will always be in sync, regardless of what that value is.

Is there any way to do this? To have all four instances offset randomly, independently from each other?

One thought is that I may be able to generate 4 random values in the parent graph and feed them into the tool graphs using the new value processors. I think this might give me real randomness. This is another reason to add that feature I've been asking for - random inheritance, where child graphs can rely on the same random pool as parent graphs.

Is there a simpler way to pull it off?

Thanks for the help!

EDIT: I just realized I can just expose the offset and send a random value that way from the parent graph without a value processor. Oops. This is probably the best way to handle it?

EDIT2: Nevermind that edit. When a value is exposed from a graph and the function for it uses a random output on the parent graph, it still generates from the internal graph random seed apparently. So value processors may indeed be required.

12
I'm having a lot of issues with randomness working correctly. Or perhaps I just don't understand how to make the best use of it.

I created a tool graph that will be employed by a secondary graph that will be employed by a parent graph. The tool graph randomly offsets the image, using a transform, by a random amount between -1 and +1. I do this by randomly generating a value between 0-2 and subtracting 1 (so 2->random->minus1). However, when I change the random seed of the tool graph by 1, the image literally moves by about 0.01. And when I change it by +1 again, it moves by the exact same amount again. This means the random value is directly offset by the random seed, by a very specific, predictable amount.

If I place 4 instances of the tool graph into the secondary graph, and choose completely different random seeds for each one (such as 21, 191, 361, 691), then add them all into a single image with blend nodes, it looks good at first. But guess what happens when I choose a different random seed for the secondary graph? All four instances of the tool graph remain in-sync, and all of them offset by the same amount, regardless of what random seed I choose. There is no way to get them to offset differently from one another. How do I get all four of them to offset by a different, random amount?

If this is just how things are, then this is not how randomness should work. If a random seed is offset by a single digit, the output should be completely randomized again, right? Not just the same result as last time plus X. Otherwise, the random seed has a direct association with the randomly generated value. A user wanting a different result doesn't get a different result - just the same result scooted over.

This situation is easy to replicate, so I won't bother uploading a graph unless someone wants me to. I just need help understanding how to make things randomize. Thanks!

13
Awesome, thanks! I thought I remembered reading about it somewhere.

So I'm officially changing my feature request to optimize this feature, since it is a crucial concept. Maybe generate temporary bitmaps in the background when the context graph is loaded? It would take some time and memory to activate it, but then no lag afterward. Or maybe add this as a "static context mode" option.

Actually, I believe you guys can optimize this without switching to a static system. If you think about it, its not much different than having all of the nodes (of parent and child graphs) in a single graph. So if you attempt to deal with this situation as if all of the related nodes belong to a single graph, it shouldn't be any more performance loss than working on a large graph. Probably a lot easier said than done, but I have hope!

14
I'm not sure what these little dot connectors are called that you create by dragging while holding Shift + Alt, but I will call them link joints. There is an issue related to these when using box selections (drag select).

Typically, when you box select multiple joints, they can be in one of two states - either their associated links are "on top" of them (the link is drawn over top of the joint), or "underneath" them (the link is drawn under the joint). I can't say for certain, but the determination of which state each one ends up in when it becomes box selected seems random, or at least difficult to understand. But when the link is in the "on top" state where it is drawn over top of the joint, the joint becomes impossible to hover with the mouse anymore, and therefore, cannot be moved around or such. Unfortunately, it seems that they end up in this state the majority of the time, and the only way to select and drag multiple joints is to temporary select an unrelated nearby node, and drag it with them, then drag the node back where it was afterward.

Once in a while, a link ends up in the "underneath" state, which allows it to be hovered by the mouse even while it is selected along with other joints. This allows easy, user-friendly dragging of multiple joints to reposition them, which is what one would expect. This situation needs fixed so that joints are always in this state when they are selected.

To reproduce the issue, just box select multiple link joints and try to drag them around. If you get the same outcome I do, then most of them will show their corresponding links over top of them. Notice that when you hover the joints with your mouse, only the ones that have the link under them will show the cursor-hover outline. The others are "in the background" and cannot be interacted with.

Example image:


15
Similar to how we can use bitmaps as temporary placeholders for input nodes, we should also be able to use data from other loaded graphs. I'm hoping this feature already exists and I just haven't figured out how to activate it. If not, something that really needs added is the ability to generate placeholders for all inputs of a graph when that graph is "referenced by a loaded graph".

So, for example, if I insert graph "child" into another graph, "parent", then connect 5 inputs to child from parent's nodes - when I use "open reference" on the child node, it should automatically associate those 5 inputs from parent to the child node, so that all of its inputs are synced to the parent node graph. If not automatically, then at least through some type of command.

If this is currently possible, please let me know how!

Pages: [1] 2 3 ... 12