Posts made by d_schmidt

Hi @m_adam ,

Thank you so much! That was exactly what I needed.

Dan

Hello, I'm using a Volume Builder, with Volume Type Fog and I'm getting some results I didn't expect with the location of the voxels. Would it be expected that the entire Volume would be filled and 'solid' with Fog mode?

It's not the most elegant test case, but it's the one I can trim down.

//Get the volume from the volume builder object.
maxon::Volume       volume = volumeObject->GetVolume();
maxon::GridIteratorRef<maxon::Float32, maxon::ITERATORTYPE::ON> iterator = maxon::GridIteratorRef<maxon::Float32, maxon::ITERATORTYPE::ON>::Create() iferr_return;
iterator.Init(volume)iferr_return;
maxon::Matrix transform = volume.GetGridTransform();

BaseDocument* doc = GetActiveDocument();
BaseObject* sphere = BaseObject::Alloc(Osphere);
BaseContainer* con = sphere->GetDataInstance();
con->SetFloat(PRIM_SPHERE_RAD, 5);

for (; iterator.IsNotAtEnd(); iterator.StepNext())
{
                const maxon::IntVector32 coord = iterator66.GetCoords();
                BaseObject* clone = static_cast<BaseObject*>( sphere->GetClone(COPYFLAGS::NONE, nullptr));
                clone->SetAbsPos(transform* Vector(coord));
                doc->InsertObject(clone, nullptr, nullptr);
}

This code will create a sphere at the location of each active voxel. This was the easiest way I could think of showing the active voxels.

If I use a cube underneath a Volume Builder and delete away some of the spheres then the hollow inside, which I didn't think would happen with Fog mode.

Screenshot with the spheres deleted to show the hollow interior.

Dan

Thank you so much! I couldn't ask for a more thorough response.

Dan

Hello, I noticed there seemed to be a new 'name' feature with the Condition object.

Is it possible to make use of it in a plugin?

'Condition' is just the object's Name, but I can't figure out how 'distance' is set.

Dan

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);