The inner network is not usable as it is now.
The main function of the inner network should be "information hiding"
If I load a clipfile:
<terragen_clip>
<constant_scalar
name = "outernode"
gui_use_node_pos = "1"
gui_node_pos = "-640 1440 0"
gui_group = ""
enable = "1"
input_node = ""
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
scalar = "0"
>
<constant_scalar
name = "intermediatenode"
gui_use_node_pos = "1"
gui_node_pos = "-240 160 0"
gui_group = ""
enable = "1"
input_node = ""
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
scalar = "0"
>
<constant_scalar
name = "innernode"
gui_use_node_pos = "1"
gui_node_pos = "-320 100 0"
gui_group = ""
enable = "1"
input_node = "\outernode\intermediatenode"
gui_use_preview_patch_size = "0"
gui_preview_patch_size = "1000 1000"
scalar = "0"
>
</constant_scalar>
</constant_scalar>
</constant_scalar>
</terragen_clip>
the assignment to the input of the inner node is lost.
Worse if you make the assignment inside tg2tp it goes puf.
I don't think you can create an inner network just by nesting elements. Create a TGD with a population of a TGO object and then look at the code. There are no path specifications in node names like input_node = "\outernode\intermediatenode". It looks like an element specific feature rather than one you can manually create. There are plans for better grouping of nodes, but for now it looks like this isn't possible.
What I mean, is when you look Davids excellent pyramid and dunes, it would be much easier to get an overview, if the Terrain group looked as shown below, and the
details was hidden inside the 3 upper nodes, insteading spreading the details over the whole global network. It helps of course that the details are grouped.
It sounds like what you're asking for is collapsible grouping or "macro" capability (similar to World Machine). This is a feature we intend to implement a later time. You can't currently use groups this way or create your own nested/internal networks for nodes. Internal networks are created automatically for certain specific node types.
- Oshyan
Talking about network: Sometimes, when i delete a shader, rests of the connected shader network remains. You don't see that in the shader list, only in the network view.
Quote from: RealUser on April 10, 2007, 07:24:58 AM
Talking about network: Sometimes, when i delete a shader, rests of the connected shader network remains. You don't see that in the shader list, only in the network view.
Yes, this is a known problem. Managing synchronization between the network view and node lists is a difficult problem that will take some more time to fully refine.
- Oshyan
Well, it's causing no crashes or something, so this is a minor problem to me.
By the way, when you duplicate a node (ctrl d), not only the the name of the node is changed, but also the names of the nodes in the internal network?
All node names must be unique within the tgd regardless of their position. You could reuse the internal network of your original node by right-clicking on the nodes input and reassigning the shader to the original's, but it wouldn't appear in the internal node network view of the duplicate. You can also link to other nodes outside of the internal network but it can get confusing because there is no visual cue that it is linked.
Quote from: mogn on April 13, 2007, 03:30:47 AM
By the way, when you duplicate a node (ctrl d), not only the the name of the node is changed, but also the names of the nodes in the internal network?
Thanks for after many years implementing a better name service in tg4.
Thanks mogn. Please look out for bugs and let me know if it misbehaves.
One consequence of this change is that some projects created in TG4 may not load properly in TG3 if they violate TG3's more strict rules on duplicate names.
Matt
The following experiment changes the name "add scalar 01" by adding _1:
Create a add scalar node: "add scalar 01"
In the inner network create "add scalar 02"
leave the inner network.
Copy (ctrl c) to the clip bord.
Enter the inner network and insert from clip board (ctrl v)
The two 02 adds are not changed, but the name of the 01 node is.
Quote from: Matt on July 05, 2016, 04:29:57 AM
One consequence of this change is that some projects created in TG4 may not load properly in TG3 if they violate TG3's more strict rules on duplicate names.
Yep. Found that out the hard way.
Quote from: mogn on July 08, 2016, 05:00:21 AM
The following experiment changes the name "add scalar 01" by adding _1:
Create a add scalar node: "add scalar 01"
In the inner network create "add scalar 02"
leave the inner network.
Copy (ctrl c) to the clip bord.
Enter the inner network and insert from clip board (ctrl v)
The two 02 adds are not changed, but the name of the 01 node is.
I'm looking into it now. A simpler way to demonstrate this limitation is to simply copy a node into its own internal network, e.g. create an add scalar node ("Add scalar 01"), copy, go to its internal network, paste.
I might be able to remove this limitation for 4.0. But this will be another change that means that some projects and clips saved in TG4 will have broken connections when loaded into TG3.
Matt