Oh wait, I think I found a way. In case anybody else wants to know, here it is...

In the PrefsDialogObject:

Bool MyPrefsDialog::SetDParameter(GeListNode *node, const DescID &id,const GeData &t_data,DESCFLAGS_SET &flags)
{
	BaseContainer* bc = MyPlugin::GetPreferences();
	if (!bc)
		SUPER::SetDParameter(node, id, t_data, flags);
	
	switch (id[0].id)
	{
		// If PREFS_MYPLUGIN_SOMEVALUE was changed, store value and notify plugin objects in all open documents.
		case PREFS_MYPLUGIN_SOMEVALUE:
			bc->SetInt32(PREFS_MYPLUGIN_SOMEVALUE, t_data.GetInt32());
			flags |= DESCFLAGS_SET::PARAM_SET;
			
			// Iterate open documents
			for (BaseDocument *doc = GetFirstDocument(); doc; doc = doc->GetNext())
			{
				// Send broadcast message to each document, use unique ID
				doc->MultiMessage(MULTIMSG_ROUTE::BROADCAST, MyPlugin::UNIQUE_ID_PREFS, nullptr);
			}
			
			GeUpdateUI();
			return true;
	}
	
	return SUPER::SetDParameter(node, id, t_data, flags);
}

And then, in the plugin object:

Bool MyPluginObject::Message(GeListNode *node, Int32 type, void *data)
{
	if (type == MyPlugin::UNIQUE_ID_PREFS)
	{
		GePrint("Aha! My prefs have changed!"_s);
		return true;
	}
	return SUPER::Message(node, type, data);
}

And in deed, having the option of executing the source protector using a command line argument for Cinema 4D, or using c4dpy would be great for integration in a plugin build pipeline.

Hi,
I'll just chime in here, as I'm involved in that project, too.

So the token hook needs to access certain elements of the scene to get their values, and the problem (thankfully) is easily reproducible.

I wrote a sample plugin that recreates the behaviour by simply returning data from the first object in the scene. Download it from our dropbox: tokenhookbug.zip

Here is the code:

This is the render setting in my example scene (which just contains a Cube):

Here is the render result in the Picture Viewer, notice the correct file name:

Uploading and rendering the file on TeamRender produces this:

The debugger clearly shows that doc->GetFirstObject() returns nullptr.

Cheers,
Frank

It works like a charm!
Thank you again!

I was surprised at how little code was required.

Sharing is caring. In case anyone needs it, here's the code:

#include "ge_prepass.h"
#include "c4d_general.h"
#include "c4d_baselinkarray.h"
#include "c4d_basedocument.h"

///
/// \brief Registers observers and sends messages to them.
///
class Observable
{
public:
	///
	/// \brief Subscribes a new observer.
	///
	/// \param[in] observer Pointer to an AtomGoal
	/// \param[in] doc The document that owns the AtomGoal
	///
	/// \return A maxon error object if anything went wrong, otherwise maxon::OK
	///
	maxon::Result<void> Subscribe(C4DAtomGoal *observer, BaseDocument *doc);
		
	///
	/// \brief Unsubscribes an observer
	///
	/// \param[in] observer Pointer to an AtomGoal that has previously been subscribed
	/// \param[in] doc The document that owns the AtomGoal
	///
	void Unsubscribe(C4DAtomGoal *observer, BaseDocument *doc);
		
	///
	/// \brief Sends a messages to all subscribed observers
	///
	/// \param[in] type Message type
	/// \param[in] doc The document that owns the subscribed observers
	/// \param[in] data Optional message data
	///
	void Message(Int32 type, BaseDocument *doc, void *data = nullptr) const;

private:
	BaseLinkArray _observers;
};

maxon::Result<void> Observable::Subscribe(C4DAtomGoal *observer, BaseDocument *doc)
{
	if (!observer)
		return maxon::NullptrError(MAXON_SOURCE_LOCATION, "Observer must not be nullptr!"_s);

	// Check if this observer is already registered
	const Int32 observerIndex = _observers.Find(observer, doc);
	if (observerIndex != NOTOK)
		return maxon::OK;

	// Register new observer
	if (!_observers.Append(observer))
	{
		return maxon::OutOfMemoryError(MAXON_SOURCE_LOCATION, "Failed to add observer to the list!"_s);
	}

	return maxon::OK;
}

void Observable::Unsubscribe(C4DAtomGoal *observer, BaseDocument *doc)
{
	if (observer && doc)
	{
		const Int32 observerIndex = _observers.Find(observer, doc);
		if (observerIndex != NOTOK)
		{
			_observers.Remove(observerIndex);
		}
	}
}

void Observable::Message(Int32 type, BaseDocument *doc, void *data) const
{
	for (Int32 i = 0; i < _observers.GetCount(); ++i)
	{
		C4DAtomGoal *atom = _observers.GetIndex(i, doc);
		if (atom)
		{
			atom->Message(type, data);
		}
	}
}

Hi Adam, happy new year to you, too!

Since it works now, for some reason, I am pretty happy with what I have. However, since it might interest other plugin developers, I'll share more code. Maybe you have some tipps about improvements or potentially dangerous stuff, too.

The idea is that the shader has a LINK field where the user can link an object (which is also part of my plugin). The object can (but doesn't have to) provide a list of "custom outputs" that will be added to the shader's CYCLE. In the screenshot below it's the "Difference Map".

When a rendering is started, the shader will request the according data from the linked object during InitRender(). But that's not part of this thread

The shader's GetDDescription():

Bool TerrainOperatorShader::GetDDescription(GeListNode *node, Description *description, DESCFLAGS_DESC &flags)
{
	iferr_scope_handler
	{
		GePrint(err.GetMessage());
		return false;
	};

	if (!description->LoadDescription(node->GetType()))
		return false;
	flags |= DESCFLAGS_DESC::LOADED;

	BaseDocument* doc = node->GetDocument();
	const BaseContainer& dataRef = static_cast<BaseShader*>(node)->GetDataInstanceRef();
	
	// Hide or show attributes, depending on shader mode
	const Bool slopeMode = dataRef.GetInt32(XTERRAINOPERATORSHADER_DATA) == XTERRAINOPERATORSHADER_DATA_SLOPE;
	TF4D::GUI::ShowDescription(node, description, XTERRAINOPERATORSHADER_SLOPE_DIRECTION_ENABLE, slopeMode);
	TF4D::GUI::ShowDescription(node, description, XTERRAINOPERATORSHADER_SLOPE_DIRECTION, slopeMode);

	// Get linked object
	BaseObject *linkedObject = dataRef.GetObjectLink(XTERRAINOPERATORSHADER_OPERATORLINK, doc);
	if (linkedObject)
	{
		// Get linked object's NodeData
		TF4D::BaseTerrainOperatorData* linkedOperator = linkedObject->GetNodeData<TF4D::BaseTerrainOperatorData>();

		// Get list of custom outputs (these are the elements to add to the CYCLE)
		maxon::BaseArray<TF4D::GUI::CycleElementData> customOutputs;
		if (linkedOperator->GetCustomOperatorOutputs(customOutputs))
		{
			if (!TF4D::GUI::AddCycleElements(node, description, XTERRAINOPERATORSHADER_DATA, customOutputs, true))
				iferr_throw(maxon::UnexpectedError(MAXON_SOURCE_LOCATION, "Could not add LONG CYCLE elements!"_s));
		}
	}

	return SUPER::GetDDescription(node, description, flags);
}

The linked object's NodeData's GetCustomOperatorOutputs():

Bool ErosionOperator::GetCustomOperatorOutputs(maxon::BaseArray<TF4D::GUI::CycleElementData>& customOperatorOutputs) const
{
	iferr_scope_handler
	{
		GePrint(err.GetMessage());
		return false;
	};

	customOperatorOutputs.Reset();

	// GetCustomOutputName() simply returns a maxon::String
	customOperatorOutputs.Append(TF4D::GUI::CycleElementData(TF4D_CUSTOMOUTPUT_EROSION_DIFFERENCE, GetCustomOutputName(TF4D_CUSTOMOUTPUT_EROSION_DIFFERENCE))) iferr_return;

	return true;
}

Cheers,
Frank

Ah, damn. Now I've spoiled that I'm working on erosion for Terraform4D

Why don't you avoid all those difficulties and simply implement that dialog using the C4D UI?

If you're storing data in the tag's BaseContainer, you don't need to override Write() and Read(). That's meant for private class member whose data would be lost otherwise.

Also, you can remove the "return true" at the end of the functions. As you already return in the previous line, it will never be called.

I did today, including it in projectdefinition.txt worked smoothly, thank you!
If I ever find out why copying it do the folders does not work, I'll post it here.

Oh my god. the stupidest error....
OK, question 1 solved already, thanks

Ah, great, thank for checking!
Then I don't need to worry about my bmp code

Cheers,
Frank

Hello,

I mostly develop on macOS and use Windows for builds only. So far this has always worked.

But not today, I have this happening reproducibly now for all my objects:

Unhandled exception thrown: read access violation.
DescID::operator[](...) returned 0x7FF8C640C128.

Running Cinema with the plugin in Release mode will freeze Cinema. In Debug mode, I see what's shown on the above screenshot.

Any ideas?

Cheers,
Frank

Thank you, Manuel! I'll try that!

Cheers,
Frank

In a .res file?

Just add DEFAULT 1; to the group's properties:

GROUP MY_GROUP
{
    DEFAULT 1;

    REAL SOME_PARAMETER { }
    LONG SOME_OTHER_PARAMETER  { }
    // and so on...
}

Hi Ferdinand,

thanks for your answer! What would the standard way of maintaining such a hidden material look like?

Something like this, I guess:

• When plugin object is created:
  • Create material
  • Hide material (NBIT_OHIDE)
  • Create texture tag on plugin object and link material
  • Hide texture tag
  • Store a BaseLink to the material as object class member
• If anything changes in the plugin object:
  • Get pointer to material from BaseLink
  • Update material with new data
• When plugin object is removed:
  • Remove and free material

But when is the right moment for creating and freeing the material? Doing it in ObjectData::Init() does not work, because a) that function is called quite often, and b) when Init() is called on object creation, the node pointer is NULL.
I also tried MSG_DOCUMENTINFO with type MSG_DOCUMENTINFO_TYPE_OBJECT_INSERT, but it's not called when the object is added to the document.

How does the Sky Object solve this?

Cheers,
Frank

Thank you, Ferdinand!

Since the Sky Object is using the trick with the hidden material, I think it is an adequate method of solving this. The material just needs to be created when the object is created, kept track of and updated with changed parameters, and then removed when the object is removed. I'll see to that and will be back if more questions arise.

Cheers,
Frank

Unfortunately, that's not enough. I need arbitrary colors on the object's surface. Vertex colors would've been ideal, but they don't appear if the Vertex Color Tag is inside my generator's cache. Or would OBJECT_USECACHECOLOR allow me to have the vertex colors appear in the viewport?

Anyway, doesn't really make a difference. Vertex colors are only drawn without shading. Therefore, I would very much prefer the SkyObject-like solution with the hidden material.

Edit:
I just realise, it should be possible to hide material and texture tag with GeListNode::ChangeNBit(OHIDE). Maybe that already solves my problem Will try tomorrow.

Thanks,
Frank

There is a way to have an invisible material in the document... The "Active Object Dialog" example plugin from cinema4dsdk reveals that there's an invisible Sky Material in the document when a Physical Sky Object is created Can I do that with a standard material, too?

Cheers,
Frank

Sorry, forgot about the tags. Added now.
It's C++.

So, as I see from that other thread, my options are pretty limited.

For my purpose, drawing must be fast (millions and millions of polygons), and it should not require the user to create and attach a material to the object. I guess it's not possible to have a hidden material in the document and attach a hidden TextureTag to the object, right?

Cheers,
Frank

Actually, after playing with this a little, I decided not to use Vertex Colors, because the Vertex Colors display does no shading.

So, let me rephrase my question:

How would I achieve colouring my plugin object on a per-vertex basis, and display it in the viewport with shading?

Thanks in advance,
Frank

Hi,

my generator object returns geometry (a PolygonObject) from ObjectData::GetVirtualObjects(). Pretty standard. Now I want to color the object, so it doesn't look just grey by default.

The most obvious answer to this would probably be vertex colors. Therefore, I am attaching a VertexColorTag to the geometry and fill its data.

Sadly, the vertex colors are not visible. If I convert my generator with "c", and then select the VertexColorTag on the resulting PolygonObject, the colors are displayed fine. But is there a way to show them, while the PolygonObject and its VertexColorTag are still in my generator's cache?

And if that's not possible, is there any other way to have default colors on an object that I return from a generator?

Thanks in advance & greetings,
Frank