Hello @ferdinand,
thank you again for this very detailed and helpful reply!

I tried both methods, allocating beforehand and like the previous setup, just have it after the ParallelFor altogether.
Both worked, although allocating beforehand introduced some weird flickering in the particles and was (at least it feels that way) more unstable.
Which is why I opted to go for the second solution as with some exstensive testing it didn't seem to cause any issues.
For anyone maybe reading this in the future and having the same issues:
Do not allocate the particle group inside the plugin but use a link field and have the user handle the particle group creation inside c4d, that solved a lot of weird behaviours and seemed to work better/more stable. (at least in my not so intended usecase)

I will mark this thread as solved, as it works now and I can fix the main-thread issue as well without too much trouble.

So thank you very much for your quick and very detailed replies!
Best Regards,
Florian

Hello @ferdinand,
thank you for you reply!
I am sorry, I should have been more specific.

• I am currently doing everything in ObjectData::ModifyObject() and was (am) using TP_MasterSystem::AllocParticle().
• The (maximum) number of particles I would allocate is always bound by the point count of the object I am modifying.

The simplyfied version of my ParallelFor routine in ModifyObject is like this:

	Matrix m;
	m = (~mod_mg) * op_mg;
	auto worker = [.../*There would normally be more here*/](maxon::Int i)
		{
			Vector  p;
			
			//holds information about the sampled result
			sample_t result;
			
			p = m * m_padr[i];
			
			//these calculations are expensive, thats why the parallel for in the first place
			result = sampler->doSomeCalculations(p.x, p.z);

			p += result.deformVector;

			m_padr[i] = ~m * p;
			}
		};
	maxon::ParallelFor::Dynamic(0, m_pcnt, worker);

where this sample_t result would also hold information (for that point) if it should spawn a particle for it, its lifetime/velocity etc. are derived from that as well.
And currently right after this ParallelFor I have this (also simplified):

       Vector  p;
	Float32 particleValue;
	for (int i = 0; i < m_pcnt; i++)
	{

		p = m * m_padr[i];
		result = sampler->doSomeCalculations(p.x, p.z);
		particleValue = 1 - result.particleValue;
		
		if (particleValue > 0) //should a particle even be spawned
			if (i % m_particleReduction == 0)  //just some simple reduction for viewport speed
			{
				if (m_masterSystem)
				{
					Int32 particle = m_masterSystem->AllocParticle();
					if (particle != NOTOK)
					{
						m_masterSystem->SetLife(particle, ...);
						m_masterSystem->SetColor(particle, ...);
						m_masterSystem->SetPosition(particle, op_mg * m_padr[i]);
						m_masterSystem->SetVelocity(particle, ...);
						
						if(m_ioParticleGroup)
							m_masterSystem->SetGroup(particle, m_ioParticleGroup);
					}
				}
			}
		}

Since doing TP Allocation in ObjectData/ModifyObject is not something I should do, where else, appart from maybe Message would be a place for that? The only information for pre-allocation that I would need is the point count of the object to modify.
Or should I scrap the idea of generating the particles on my own alltogether? The plugin itself should later on be used in a more dynamic (mesh - subdivisions etc.) context that's why I initially did not want to simply set vertex weights as that would not quite work for the use case of this plugin.
Hope I could give more useful information on what it is I am trying to achieve.

Thanks again for your quick and detailed reply!
Best Regards,
Florian

Hello PluginCafe!
I am currently working on an Object Modifier plugin and wanted to integrate Thinking Particles alongside the deformation.
The deformation of the points is done in a ParallelFor loop (which works fine and is needed) but even just trying to allocate a particle inside of the worker leads to access violations and a Cinema4D crash.
However if I loop through the pcnt again outside/after the initial deformation (after the parallel for) everything works as expected.

So my assumption is that Thinking Particles don't really like ParallelFor/multiple threads?
Is this a general limitation of Thinking Particles or is there some threading issue that I have missed in the documents/am not aware of?

If possible I would like to move all the TP-Allocation stuff into the parallel for as I have to (in the context of this plugin) do most calculations twice otherwise.
The current target version I am developing this plugin for is R20 (and all versions after).

Thanks in advance!
-Florian

Hello Manuel,
thanks for your input!
I got it working correctly with the values you mentioned.
Reading through the docs again I feel kinda dumb for not getting it right myself.
Thanks to both you and zipit for your great help!

Best Regards,
Florian

Hello zipit,
thanks for your quick reply!

I actually only need one direction, one up and one position vector. I am trying to parse a (generic) scene with the camera and everything from Cinema4D to another program/renderer which has a right handed coordinate system. And for the Camera I do need the up, position and direction vector.

I will read through what you suggested tomorrow, thanks for the throughout reply!

Best Regards,
Florian

Hello PluginCafe,
I have been stuck on the problem of converting Camera Position / Rotation
to position, direction and up vectors for a right handed system. It is probably really easy and I am just being brain dead right now but I have been struggling for way longer than I want to admit.

I hope somebody can help me there,
Florian

Hello Sebastian,
I now understand what the difference is, thank you very much!
With the customdata_customgui example file I actually made both a GUI and a custom DataType. So I only needed to change my resource file and modifiy my data code a bit!

Best Regards,
Florian

oh... yeah that is true.

I edited the customdata_customgui example to fit my needs. (mainly only the drawing).
So I guess I would have to change my customdata to a REAL customgui?

Hello Sebastian,
basically I have something like this

[...]
MY_CUSTOMGUI CUSTOMGUIPARAM { }
[...]

that is what I use.

Hello Maxime,
thanks for you answer!
I actually have my custom gui not in a GeDialog but inside a res file of an ObjectData. How would I be able to access the customgui from there?

Best Regards,
Florian