Thanks for looking into it @m_adam.
Maybe this is specific to Arnold, but there are shader parameters that are not linkable. It's a flag on the parameter. Typically, boolean and enum type parameters are not linkable, like the ones highlighted in the screenshot below. But could be any parameters really, depending on the shader code.
Hi Ferdinand,
Thank you for your reply. Sorry for not being completely clear. Yes, I meant maxon::nodes::ReqOrderIndex. I feel like it would be more natural if the input menu would match the order in the Attribute Editor, instead of listing the items in alphabetical order. Being able to control the behavior via the API could be welcome. I'll make a feature request, just in case. What's the best option to file an API request? Should I use the form in support.maxon.net or the contact form here?
Thanks,
Peter
Hi Ferdinand,
Thank you for the detailed description, it's very useful, I have a good understanding now how this should work. Yes, the main goal here is installer optimization. Unfortunately, hosting online is not an option. I'll give it a thorough testing to see if we hit any limitations with this approach, and we might drop the idea if so.
Thanks,
Peter
We set the order index of the ports and they are displayed properly in the Attribute Editor, but the input port menu does not respect this and groups and ports are displayed in a "random" order, that does not match the UI and is quite confusing.
Is this a limitation or is there a flag or other attribute we have to set to match the layout of the Attribute Editor?
Is there a flag to hide a port from the input port menu in the Node Editor. We'd like to have the parameters displayed in the Attribute Manager, but there are some that are not linkable, thus it does not make sense to have them in the input port menu.
Our plugin ships with a few material assets. I'm wondering if it's possible to install our custom asset library (asset database) as a zip file, instead of hundreds of files and folders.
Sure, no worries, it's not a high priority, more like a nice to have feature. We can manage without this. I was just wondering if something like this could be possible already in the context of node materials. Thanks.
Hi Ferdinand,
Yes, I'm referring to a reference as a BaseLink or port with a linkbox custom gui. Our legacy material using the classic API does exactly what you have described. It clones the linked node in NodeData::CopyTo(), packs it with the material and unpacks in the new scene via a scene hook/message data plugin. Not pretty, but works fine.
This level of flexibility is missing from Node Materials, so as I understand it's not possible to achieve something similar right now nor in the near future most likely. Alright, I can live with that.
Cheers,
Peter
This might be a very unique use-case.
We define a custom node system that is used in Node Materials. We have a shader that references another nodes from the scene, such as materials and objects. Currently when the Node Materials is copied over to a new scene, these references are lost. Ideally, the referenced nodes should be cloned and copied over to the new scene along with the material. Is it possible to do this with the current SDK?
This was not an issue with our legacy material, since it was our custom MaterialData implementation, and so we had control over copying by overriding the CopyTo() method.
Thanks Ferdinand, that makes sense. Will do the preroll step in my code. Cheers.
Hi Ferdinand,
Thank you for the update. Your python script works indeed, however, weirdly, doing the same thing from c++ still fails. You can check with my sample code attached above.
Edit: I went back to 2024.4.0 and tried the python script there as well and it was working. Not sure what's different between the two calls, but the issue seems to be c++-specific.
Cheers,
Peter
Hey Ferdinand,
Thank you for investigating and digging deep on the topic, much appreciated. I'll handle this as a limitation for now, until an official solution exists. But don't worry, it's not a high priority for us at the moment.
Thank you,
Peter
Hey Ferdinand,
Thank you for looking into this. Yes, this is about implicitly animated shaders, like the noise you mentioned, or an image sequence in the Image/Texture shader. You are right, it does not work in the Standard node space, only in Redshift, so might be indeed some custom solution there. What is the Animate Preview checkbox for then, if you don't mind me asking.
I was also thinking about a workaround that triggers an update in the graph explicitly upon frame changes, if no standard solution exists. Don't worry about putting that together, I think I'll manage.
Cheers,
Peter
I'd like to add support for animated previews in my custom node space. I assumed, that enabling Animate Preview on the Viewport tab of the material means that the GetMaterialParameters() function of my viewport material is called every time the frame changes in the scene.
However that does not seem to be the case, nothing happens when moving the timeline. Am I missing something? Do you have an example of how to support animated previews?
Thank you for taking time on this. Definitely promising. I'll give it a spin to see if I can reach the desired results with any of the mentioned approaches.
Hey Ferdinand,
Thank you for your prompt answer. Yes, I'm talking about parameter groups, like the Base or Reflection group in the Redshift Material and the groups do not exist yet. The goal here is to create these parameter groups and the parameters within them dynamically based on an integer input that defines the number of groups.
Thanks,
Peter
dynamic_node_impl.cpp from the example.nodes project shows how to add simple int/string/color parameters (input ports) to a Node dynamically.
maxon::Id portId;
portId.Init(part) iferr_return;
// Add port for part.
maxon::nodes::MutablePort port = root.GetInputs().AddPort(portId) iferr_return;
// Make a dependency connection from input to output. This tells the system which
// ports are needed for the shader evaluation of the output port.
port.Connect(output, maxon::Wires(maxon::Wires::DEPENDENCY)) iferr_return;
if (part[0] == 'i')
{
// Create a port of type Int.
port.SetType<maxon::Int>() iferr_return;
// Directly set the name.
port.SetValue(maxon::NODE::BASE::NAME, part) iferr_return;
}
...
Is it possible to add UI groups as well and set them as parent groups of these ports?
Hey Ferdinand,
Thanks for the reply. Sorry, I forgot to include the test scene. It was just a simple Basic Emitter and I rendered it with Redshift.
You could combat that with setting the cloned document to frame 0 and then executing the passes up to the point where you want to render.
Yeah, I've tried that actually, but did not solve the problem.
I logged the issue as ITEM#506966 (including the tests scene in the zip this time).
It is not critical for us at the moment, since this is a specific use-case and not using the NODOCUMENTCLONE flag can be a good workaround.
Thank you,
Peter
Hey Ferdinand,
Nothing special about the context. Tried cloning with AliasTrans, but it does not help.
I'm attaching a simple code taken from the manual in case you want to reproduce the issue. The code adds two commands, one calling RenderDocument() with the RENDERFLAGS::NODOCUMENTCLONE flag and one without. You can see, that the one with the flag does not render the particles. Note, that no manual cloning is involved in the example, just loading the document, which might indicate that it's indeed a bug.
Thanks,
Peter
I have a scene with the new 2024.4 particles, like a default Basic Emitter for instance.
I clone the scene and then call RenderDocument() with the NODOCUMENTCLONE flag on a thread, however that does not render the particles.
BaseDocument* renderDocument = static_cast<BaseDocument*>(myDocument->GetClone(COPYFLAGS_DOCUMENT, nullptr));
...
RenderDocument(renderDocument, renderSettings, nullptr, nullptr, bitmap, RENDERFLAGS_EXTERNAL | RENDERFLAGS_BATCHRENDER | RENDERFLAGS_NODOCUMENTCLONE, this->Get());
If RenderDocument() is called without the NODOCUMENTCLONE flag, then the particles are rendered fine.
I assume when RenderDocument clones the scene, it also triggers the particles to be simulated. Can you help me with what's missing to achieve the same behavior?
Have to note, no issue, if the particles are cached.