Posts made by d_schmidt

Thanks for the info!

Dan

Hi @i_mazlov

Sorry about the lack of clarity in my post, I managed to trim the case down to something pretty narrow:

The hierarchy:

The code:

  BaseObject* firstChild = op->GetDown();
    if(firstChild != nullptr)
    {
        if(firstChild->GetType() == Ovolumebuilder)
        {
            VolumeBuilder* volumeBuilder = static_cast<VolumeBuilder*>(firstChild);
            if(volumeBuilder!=nullptr)
            {
                Int32 volumeBuilderInputCount = volumeBuilder->GetInputObjectCount(false);
                BaseObject* volumeChildInput = volumeBuilder->GetDown();
                
                if(volumeBuilderInputCount > 0 && volumeChildInput != nullptr)
                {
                    BaseObject* volumeInputObject = volumeBuilder->GetInputObject(0);
                    if(volumeChildInput == volumeInputObject)
                    {
                        ApplicationOutput("The two inputs are the same.");
                    }
                    else
                    {
                        ApplicationOutput("The two inputs are not the same.");
                    }
                    
                }
            }
        }
    }

In most cases it seems like the two objects equal each other, e.g. if the cube is moved. If an Undo is performed after moving the cube, so the Undo returns the cube's position back, then they do not equal each other.

This is the same circumstance where I'm not able to retrieve the cache from the GetInputObject() object. Would this be expected behavior in this circumstance?

Dan

Hello, I have a circumstance pretty far in my code where I'm using a VolumeBuilder.

If I have a cube as a child of a VolumeBuilder when I use GetInputObject to retrieve that cube, I'm not able to get the cache from that cube sometimes with GetCache().

In the same circumstance, if I use GetDown() from the VolumeBuilder, to retrieve that cube, I am able to get the cache from that cube same cube with GetCache().

Do GetInputObject() and GetDown() behave differently in this circumstance?

Thanks for the help!
Dan

Hi Ferdinand,

So to be clear, the only thing that can be done with ItemTreeData is adding new objects to it?

Thanks,
Dan

Hi Ilia,

At this point this seems a bit over my head, but it seems to be what I need, thanks!

Dan

Hello, I've just started to dive into Redshift materials and I was wondering if there is a way to sample them like a Standard material?

I've had some success with Standard materials with using BaseShader::Sample() and BaseChannel::Sample() to get the values of specific shaders at given positions. I can't find a similar way to sample a Redshift material.

Dan

Hi Ilia,

I'm on Mac 13.3 and C4D 2024.0.0 at the moment.

Dan

Hello, @i_mazlov

You're exactly right about what I'm trying to achieve. Thanks again for the answers.

With your code, placed in RoundedTube, seems to work in that the VertrexColorTag is preserved between updates and I can see the tag changes as it's updated.

I am encountering an issue where if I increasing and decreasing Rotation Segments I'll occasionally get a crash. Sometimes the crash is pointing to this line: "CheckState(pKernel->Commit());" but other times I'm not getting a particular crash location. Do you encounter this issue?

Then, when I implement your fix into my code, everything seems to be working well, until I shrink down the number of points I have. When increasing the number of points it seems like the VertexColorTag is increasing up correctly but when I scale decrease the number of points it will crash occasionally. This isn't tied to the above crash, since I'm not using Modeling in my code. Would any tweaks need to be done to the code to handle shrinking point counts?

Dan

@i_mazlov

From my current testing it seems like CopyTo() 'work', in so far as the data is copied, but it seems to break all existing Links to the existingVertexColor VertexColorTag. Would there be a way to preserve the links?

Dan

Hi @i_mazlov
I'm currently using CopyTagsTo(), to copy the tag from the object to the cache. The problem with the methodology is that if I'm linking to the VertexColorTag externally, that deleting it and creating a new tag would break that link.

That's where I was left at this point:

PolygonObject* myGeometry = PolygonObject::Alloc(polygonCount,pointCount);

//create geometry 

VertexColorTag* existingVertexColor = static_cast<VertexColorTag*>(op->GetTag(Tvertexcolor));
if(vertexColorTag == nullptr)
{
  existingVertexColor = VertexColorTag::Alloc(pointCount);
  op->InsertTag(existingVertexColor);
}
if(pointCount != oldPointCount)
{
   VertexColorTag* largerVertexColor  = VertexColorTag::Alloc(pointCount);

   //fill in color data for the new tag, then copy it to the existing tag

  largerVertexColor->CopyTo(existingVertexColor, COPYFLAGS::NONE, nullptr);


}
else
{
     //fill in color data for existingVertexColor
}
op->CopyTagsTo(myGeometry, true, true, false, nullptr);

The problem I was encountering here is that CopyTo() doesn't seem to be copying the data from the new correct larger tag to the smaller existing one.

Should CopyTo() work here?

Dan

I'm also confused by what you meant here.

@i_mazlov said in VariableTag, Resize, and CopyTo:

How are you going to use this color data? VertexColorTag works with polygon objects, so having it on the op (the actual object that user sees in c4d) doesn't make too much sense, as it can neither be modified with the painting tool (because it sits on your plugin object, not on polygon object) nor can it be displayed (the same reason).

The VertexColorTag data can be displayed in this case. If I have the tag selected the black to white gradient is being displayed in the viewport.

Does this provide the needed context or would more details be helpful?

Dan

Hi Illia,

I haven't been able to properly stress test the new code, but by the first look it seems to be working. Thanks!

Dan

Hi Ilia, baca
Thanks for the reply.

Thanks for the example code! Is there a manual for the Modeling kernel? I took a look in the SDK but didn't see one. Would it always be better to use that approach for creating geometry?

Here's my current setup.

For more context on what I'm trying to achieve, this is my hierarchy:

"My Point Generator" is returning a series of points, a polygon object with only points, no polygons. I'm adding a Vertex Color Tag to the plugin, and copying it to my cache. Right now with the colors being random.

Then "My Point Generator" is being given to the Cloner, for the point locations. The Vertex Color Tag is put in the Field list for the Plain effector and then the Plain Effector is given to the Cloner to pass the color data on.
Right now that is working and resulting in this:

Dan

Hi @baca

So I should be creating my VertexColorTag inside of Execute() and applying it to my Generator plugin rather than the returned geometry? With that change would resizing VertexColorTag no longer be an issue?

Dan

Hi Ilia,

Looking over the Modeling kernel, that seems to be suited for taking in user provided geometry and modifying it, is that right?

In my case I'm creating original geometry to return. I'm building geometry based on attributes on my plugin. The easiest version would be that I'm creating a plane from scratch, with each polygon being made by me, using PolygonObject, GetPolygonW(), and GetPointW(). I'm manually setting all the points and polygons. If I don't return the cache(when it's not dirty) then I'm rebuilding the output from scratch.

I wanted to add color data to my points. Each update I'm creating a new VertexColorTag with the new proper size and using CopyTo() to move the data onto the existing VertexColorTag on my plugin. At the end I'm using CopyTagsTo() to copy the exposed VertexColorTag from the plugin to my returning geometry.

PolygonObject* myGeometry = PolygonObject::Alloc(polygonCount,pointCount);

//create geometry 

VertexColorTag* existingVertexColor = static_cast<VertexColorTag*>(op->GetTag(Tvertexcolor));
if(vertexColorTag == nullptr)
{
  existingVertexColor = VertexColorTag::Alloc(pointCount);
  op->InsertTag(existingVertexColor);
}
if(pointCount != oldPointCount)
{
   VertexColorTag* largerVertexColor  = VertexColorTag::Alloc(pointCount);

  

  largerVertexColor->CopyTo(existingVertexColor, COPYFLAGS::NONE, nullptr);


}
else
{
     //fill in color data for existingVertexColor
}
op->CopyTagsTo(myGeometry, true, true, false, nullptr);

Hello, I was looking to return a VertexColorTag along with a generator plugin I'm making. I'm able to do that easily enough when I'm initially creating the tag. Once the tag the exists on my plugin I don't seem to be able to modify the size of the VertexColorTag.

I saw in this: https://developers.maxon.net/forum/topic/13335/is-it-possible-to-resize-a-c4d-variabletag that while a VariableTag can't be resized, I could copy a new larger data set from a new VertexColorTag to my existing one. Is that understanding correct?

I've been struggling to actually get the new(larger) data to be successfully copied over. Would it just be C4DAtom->CopyTo() or a different methodology?

Shortened version of my existing code.

VertexColorTag* existingVertexColor = static_cast<VertexColorTag*>(op->GetTag(Tvertexcolor));
if(vertexColorTag == nullptr)
{
   existingVertexColor = VertexColorTag::Alloc(newCount);
   op->InsertTag(existingVertexColor);
}
if(newCount != oldCount)
{
    VertexColorTag* largerVertexColor  = VertexColorTag::Alloc(count);

   //fill in color data

   largerVertexColor->CopyTo(existingVertexColor, COPYFLAGS::NONE, nullptr);


}

Dan

Hello again!

I recently began working from scratch again. In @i_mazlov 's code above here: https://developers.maxon.net/forum/post/73005 I'm always getting a dirty result and this seems to be incorrect.

My GVO Is purely the provided code and all I have in the scene is my test plugin, and Volume Builder as a child, and then a Cube a a child of the Volume Builder.

Even when nothing is changed in the scene the plugin is returning that's it's dirty and being rebuilt.

Dan

Thanks Ilia! That was exactly what I needed!

Dan

Hello, I was using a Vertex Color Tag and I noticed that is was disappearing when I made the object it was on editable. I did a bit of testing and it seems like it disappears when it's on a plugin object and not a Cinema object.

For example, on the "C++ SDK - Plane By Polygons Generator Example" the Vertex Color Tag will vanish, but when on a Cube it stays as it should.

Before making editable:

After making editable:

"C++ SDK - Plane By Polygons Generator Example"'s Vertex Color Tag is gone in the second case.

The same behavior is happening with my plugin, but the SDK example seems like the clearer case. Any ideas on why this behavior would be happening?

Dan